trustchain-oc1-orchestral
/
authentik
Archived
10
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
This repository has been archived on 2024-05-31. You can view files and clone it, but cannot push or open issues or pull requests.
authentik/web/xliff/zh_TW.xlf

7972 lines
301 KiB
Plaintext
Raw Normal View History

web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<?xml version="1.0"?><xliff xmlns="urn:oasis:names:tc:xliff:document:1.2" version="1.2">
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<file target-language="zh-TW" source-language="en" original="lit-localize-inputs" datatype="plaintext">
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
<body>
<trans-unit id="s4caed5b7a7e5d89b">
<source>English</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>英語</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s75a27f43413e02c5">
<source>French</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>法語</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9d2d00982edafabb">
<source>Turkish</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>土耳其語</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf1868dc19e3917bb">
<source>Spanish</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>西班牙語</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s03f49e598ffb11cc">
<source>Polish</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>波蘭語</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4660da32fb311ac0">
<source>Taiwanese Mandarin</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>繁體中文(台灣)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s354e0a9f146d2869">
<source>Chinese (simplified)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>簡體中文</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se3e6af2ce24d80e8">
<source>Chinese (traditional)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>繁體中文</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s63e71d20d1eaca93">
<source>German</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>德語</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s49730f3d5751a433">
<source>Loading...</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>載入中……</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf1e9d421f35b51e5">
<source>Application</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s310d8757ce319673">
<source>Logins</source>
<target>登入</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa50a6326530d8a0d">
<source>Show less</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>顯示更少</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb2c57b2d347203dd">
<source>Show more</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>顯示更多</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6238f519db67980d">
<source>UID</source>
<target>UID</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sef49aec68fd1dc66">
<source>Name</source>
<target>姓名</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf9f2c719a04066ec">
<source>App</source>
<target>App</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sda796c87fa97ed4d">
<source>Model Name</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>型號名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s79e8cc71a5975b04">
<source>Message</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>訊息</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbbc53e0e54d7946f">
<source>Subject</source>
<target>Subject</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa6ab5184d6315895">
<source>From</source>
<target>来自</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s09353907b5c79284">
<source>To</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>到</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s63e03c70f67ebf9c">
<source>Context</source>
<target>上下文</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa48f81f001b893d2">
<source>User</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s119498d4e4cf59a6">
<source>Affected model:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>受影響的模型：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa3660d505e7011e0">
<source>Authorized application:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已授權的應用程式：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s95a032ae86881bf5">
<source>Using flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scb5c9a7cc4ccd68d">
<source>Email info:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>電子郵件訊息：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s677f1b675fc21bb1">
<source>Secret:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>機密密碼：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd947d57c9a9b7108">
<source>Open issue on GitHub...</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>前往 GitHub 回報問題……</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa6905be242387f36">
<source>Exception</source>
<target>例外</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6ab73c998850c5ab">
<source>Expression</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>表示式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s50ebe627b4bc7d02">
<source>Binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3c6de3f257e0c912">
<source>Request</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>要求</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s730182ad28374cda">
<source>Object</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>物件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s890e983a7be64da4">
<source>Result</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>結果</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd3a853f63f45dcb0">
<source>Passing</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通過</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbdeedc1c60306b35">
<source>Messages</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>訊息</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0a5401d4419f9958">
<source>Using source</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s14622ee6de586485">
<source>Attempted to log in as <x id="0" equiv-text="${this.event.context.username}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已嘗試以 <x id="0" equiv-text="${this.event.context.username}"/> 的身份登入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb07bf992e3d00664">
<source>No additional data available.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>没有其他可用資料。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s09810653c832e935">
<source>Click to change value</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>點擊以更改數值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfefce784ec55868f">
<source>Select an object.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇一個物件。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s04ceadb276bbe149">
<source>Loading options...</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>載入選項中……</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfe629863ba1338c2">
<source>Connection error, reconnecting...</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>連線錯誤，正在重新連線……</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc8da3cc71de63832">
<source>Login</source>
<target>登入</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb4564c127ab8b921">
<source>Failed login</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登入失敗</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s67749057edb2586b">
<source>Logout</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登出</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7e537ad68d7c16e1">
<source>User was written to</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者已經被寫入到</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa0e0bdd7e244416b">
<source>Suspicious request</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可疑的要求</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7bda44013984fc48">
<source>Password set</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>密碼設定完成</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa1b41e334ad89d94">
<source>Secret was viewed</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>機密密碼已被查看</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s92ca679592a36b35">
<source>Secret was rotated</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>機密密碼已被輪替</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8a1d9403ca90989b">
<source>Invitation used</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已使用邀請函</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5f496533610103f2">
<source>Application authorized</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已成功授權應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdc9e222be9612939">
<source>Source linked</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已連接來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb1c91762ae3a9bee">
<source>Impersonation started</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已開始模擬</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9c73bd29b279d26b">
<source>Impersonation ended</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已結束模擬</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1cd264012278c047">
<source>Flow execution</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>流程的執行事件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s32f04d33924ce8ad">
<source>Policy execution</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策的執行事件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb6d7128df5978cee">
<source>Policy exception</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策的例外事件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s77f572257f69a8db">
<source>Property Mapping exception</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>屬性對應例外事件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2543cffd6ebb6803">
<source>System task execution</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>系統工作執行事件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se2f258b996f7279c">
<source>System task exception</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>系統工作例外事件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s81eff3409d572a21">
<source>General system exception</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>一般系統例外事件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf8f49cdbf0036343">
<source>Configuration error</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定錯誤</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9c6f61dc47bc4f0a">
<source>Model created</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已建立模型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s47a4983a2c6bb749">
<source>Model updated</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已更新模型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc9f69360b58706c7">
<source>Model deleted</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已刪除模型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa266303caf1bd27f">
<source>Email sent</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已發送電子郵件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6c410fedda2a575f">
<source>Update available</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>有可用更新</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s02240309358f557c">
<source>Unknown severity</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>嚴重程度未知</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf1ec4acb8d744ed9">
<source>Alert</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警報</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9117fb5195e75151">
<source>Notice</source>
<target>注意</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s34be76c6b1eadbef">
<source>Warning</source>
<target>警告</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf45a0d2f00bcc6ff">
<source>no tabs defined</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未定義的標籤頁</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s04c5a637328c9b67">
<source><x id="0" equiv-text="${this.pages?.startIndex}"/> - <x id="1" equiv-text="${this.pages?.endIndex}"/> of <x id="2" equiv-text="${this.pages?.count}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target><x id="2" equiv-text="${this.pages?.count}"/> 個項目中的 <x id="0" equiv-text="${this.pages?.startIndex}"/> - <x id="1" equiv-text="${this.pages?.endIndex}"/> 項目</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6a89bb10338369b4">
<source>Go to previous page</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>回到上一頁</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7edad99c6b7bfe88">
<source>Go to next page</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>前往下一頁</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sffa721bb6aa3128d">
<source>Search...</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>搜尋中……</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb59d68ed12d46377">
<source>Loading</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>載入中</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7bc8c327f1f7c82c">
<source>No objects found.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>找不到任何物件。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfd44ce578f643145">
<source>Failed to fetch objects.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無法擷取物件。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7b7163270e57e8b4">
<source>Refresh</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>重新整理</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s909e876731a8febb">
<source>Select all rows</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇所有列</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa442044b586ec8bf">
<source>Action</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>動作</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s02839b01844d6ca8">
<source>Creation Date</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立日期</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4d00f1de1c82281b">
<source>Client IP</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用戶端 IP</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s45f9e7ce0897f9e5">
<source>Tenant</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>租戶</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2152f3482784705f">
<source>Recent events</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最近的事件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc35581d9c1cd67ff">
<source>On behalf of <x id="0" equiv-text="${item.user.on_behalf_of.username}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>代表 <x id="0" equiv-text="${item.user.on_behalf_of.username}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saf63a04c86018698">
<source>-</source>
<target>-</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1b448a4ea79d4eef">
<source>No Events found.</source>
<target>未找到任何事件。</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s50911ec1c8aee99a">
<source>No matching events could be found.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>找不到符合的事件。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s113c05ef9996ca4b">
<source>Embedded outpost is not configured correctly.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>嵌入式 outpost 設定不正確。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="seb5ba88f21937c98">
<source>Check outposts.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查 outposts.</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd0bc94e11935ee5a">
<source>HTTPS is not detected correctly</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未正確的偵測到 HTTPS</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s40bf151b56a64f51">
<source>Server and client are further than 5 seconds apart.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>伺服器和用戶端的時間差距超過5秒。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s091d3d07b5b3076f">
<source>OK</source>
<target>OK</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sae486938be80729c">
<source>Everything is ok.</source>
<target>一切正常。</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sea91c57b3d3969fe">
<source>System status</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>系統狀態</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scefe482c547fb3f3">
<source>Based on <x id="0" equiv-text="${value.versionCurrent}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於 <x id="0" equiv-text="${value.versionCurrent}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s68a50b1ee6efee7b">
<source><x id="0" equiv-text="${value.versionLatest}"/> is available!</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新版本 <x id="0" equiv-text="${value.versionLatest}"/> 可用！</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s713d147e1761d0f0">
<source>Up-to-date!</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最新版本！</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf4122b220926be97">
<source>Version</source>
<target>版本</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0a63a8be0b2b422c">
<source>Workers</source>
<target>Workers</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s341ab68d4130de20">
<source>No workers connected. Background tasks will not run.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>沒有已連線的 workers，無法執行背景工作。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2ed8eb02525a920a">
<source><x id="0" equiv-text="${ago}"/> hour(s) ago</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target><x id="0" equiv-text="${ago}"/> 小時以前</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1f1c857c0c4250e4">
<source><x id="0" equiv-text="${ago}"/> day(s) ago</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target><x id="0" equiv-text="${ago}"/> 天以前</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s11bc220e8fa9d797">
<source>Authorizations</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>授權</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3ef3c252ada78076">
<source>Failed Logins</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登入失敗</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc2f1e5dd74c1b7df">
<source>Successful Logins</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登入成功</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0382d73823585617">
<source><x id="0" equiv-text="${this.errorMessage}"/>: <x id="1" equiv-text="${e.toString()}"/></source>
<target>
<x id="0" equiv-text="${this.errorMessage}"/>:
<x id="1" equiv-text="${e.toString()}"/></target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2ceb11be2290bb1b">
<source>Cancel</source>
<target>取消</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se085f35c8a9203a1">
<source>LDAP Source</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>LDAP 來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s477de089b505a6ea">
<source>SCIM Provider</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SCIM 供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8a75e83497a183a2">
<source>Healthy</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>健康</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfeb82261bcf99edd">
<source>Healthy outposts</source>
<target>健康的 Outposts</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saae1c70e168b45b4">
<source>Admin</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>系統管理員</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0a11c2ffb8309d1a">
<source>Not found</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>找不到</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saa0e2675da69651b">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source>The URL "<x id="0" equiv-text="${this.url}"/>" was not found.</source>
<target>找不到網址 "<x id="0" equiv-text="${this.url}"/>"。</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s58cd9c2fe836d9c6">
<source>Return home</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>回到首頁</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s41e035c4bb8d15f2">
<source>General system status</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>一般系統狀態</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6dfd15978586d05f">
<source>Welcome, <x id="0" equiv-text="${name}"/>.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>歡迎，<x id="0" equiv-text="${name}"/>。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc381422c585b867f">
<source>Quick actions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>快速動作</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfd13ca8ebd857c2e">
<source>Create a new application</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立新的應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s079d388d3cbfa54f">
<source>Check the logs</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查日誌</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sed8d4c3fd5f60e1f">
<source>Explore integrations</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>探索整合方案</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfffb0d0958bfbc42">
<source>Manage users</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>管理使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8763a33c3d46aaf5">
<source>Outpost status</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Outpost 狀態</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scc286303aa9c6cb0">
<source>Sync status</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>同步狀態</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbdc4a833de9ca502">
<source>Logins and authorizations over the last week (per 8 hours)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>一周的登入和授權狀態(每 8 小時)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6e09a19aa3952509">
<source>Apps with most usage</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用頻率最高的應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sda5e1499f93146ad">
<source><x id="0" equiv-text="${ago}"/> days ago</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target><x id="0" equiv-text="${ago}"/> 天前</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s51ea3a244c781b1f">
<source>Objects created</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已建立物件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfbadb77fbc61efb8">
<source>Users created per day in the last month</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>上個月每天的建立使用者數量</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb0669da3df95837c">
<source>Logins per day in the last month</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>上個月每天的登入次數</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s835da49b4dc83a51">
<source>Failed Logins per day in the last month</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>上個月每天的登入失敗次數</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5f4586bc1e2740e6">
<source>Clear search</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>清除搜尋結果</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3b34d9930e33bd46">
<source>System Tasks</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>系統工作</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saaa3abe03c7260f9">
<source>Long-running operations which authentik executes in the background.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>authentik 在背景執行的長時間工作。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7468e87263dfff7e">
<source>Identifier</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>識別碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s63d894b1ddb06289">
<source>Description</source>
<target>描述</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa9b2a245441557dc">
<source>Last run</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最後執行</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sad3e3c8146fc920f">
<source>Status</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>狀態</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8af61807443f32a4">
<source>Actions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>動作</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbe9a51f29a4a2c5b">
<source>Successful</source>
<target>成功</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5f343a43e7ea9f91">
<source>Error</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>錯誤</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc592307ea80f16b9">
<source>Unknown</source>
<target>未知</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s92921878e886e36d">
<source>Duration</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>持續時間</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se7e1ababbc4868b8">
<source><x id="0" equiv-text="${item.taskDuration.toFixed(2)}"/> seconds</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target><x id="0" equiv-text="${item.taskDuration.toFixed(2)}"/> 秒</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc25edca57df81461">
<source>Authentication</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分認證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6dfb7283452f78fe">
<source>Authorization</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>授權</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sddcfc6ab24e3a6ed">
<source>Enrollment</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>註冊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1fc9c70610c4c67d">
<source>Invalidation</source>
<target>失效</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6ac670086eb137c6">
<source>Recovery</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>救援</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdf22dcf939c27cc7">
<source>Stage Configuration</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6d5bce4321f57cda">
<source>Unenrollment</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>取消註冊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sde2bb5418562c5b2">
<source>Unknown designation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未知命名</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb9834316ffd4ae3e">
<source>Stacked</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>堆疊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s12146091b2b539a3">
<source>Content left</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>內容置左</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa800871782eba1ac">
<source>Content right</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>內容置右</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb4e50ca3cffdbc10">
<source>Sidebar left</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>側邊攔置左</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s745a55f9abf9f2e5">
<source>Sidebar right</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>側邊攔置右</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb3182a87ded1bc91">
<source>Unknown layout</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未知的版面設計</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdfd22a21660f6002">
<source>Successfully updated provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新供應商。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s457c639088c547c5">
<source>Successfully created provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立供應商。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sff69c1a637f899a6">
<source>Bind flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>附加流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s319040353f479853">
<source>Flow used for users to authenticate.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於使用者認證的流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbc80eab557fbf782">
<source>Search group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>搜尋群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s04b7f8d6aaef3756">
<source>Users in the selected group can do search queries. If no group is selected, no LDAP Searches are allowed.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選中的群組中的使用者可以搜尋查詢，如果未選擇任何群組，則無法執行 LDAP 搜尋。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se5973e7c8ba0fc71">
<source>Bind mode</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>附加模式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8915e64b8b999bfe">
<source>Cached binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>儲存在快取的附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s842d690eb3c11762">
<source>Flow is executed and session is cached in memory. Flow is executed when session expires</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當流程執行後，會談訊息將儲存在記憶體中。一旦會談過期，該流程將重新執行</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6a66759749bf31ed">
<source>Direct binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>直接附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se0adaf83627104fb">
<source>Always execute the configured bind flow to authenticate the user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>總是執行設定的附加流程來驗證使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scef3f4ad80abbd22">
<source>Configure how the outpost authenticates requests.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定 Outpost 如何驗證要求。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbcae51a6f06e53d4">
<source>Search mode</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>搜尋模式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9065fcccd837a679">
<source>Cached querying</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>快取中的查詢</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s30d0d0e6c626a234">
<source>The outpost holds all users and groups in-memory and will refresh every 5 Minutes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Outpost 將所有使用者和群組保存在記憶體中，並每5分鐘重新整理。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sffc14b8200a9f938">
<source>Direct querying</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>直接查詢</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdce4680288083fe3">
<source>Always returns the latest data, but slower than cached querying</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>總是回傳最新的資料，但這會比快取查詢慢上許多</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8b87df5664de7eb8">
<source>Configure how the outpost queries the core authentik server's users.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定 Outpost 如何查詢 authentik core 伺服器上的使用者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfe388f0313f52da2">
<source>Protocol settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通訊協定設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s55d731be1ef66efe">
<source>Base DN</source>
<target>Base DN</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0b15ff11a0049cfd">
<source>LDAP DN under which bind requests and search requests can be made.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可以進行附加和搜尋要求的 LDAP DN。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb157267c85fdff30">
<source>Certificate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>憑證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sac43cb9690260b86">
<source>UID start number</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>UID 起始編號</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s60edbcfac8ed1f90">
<source>The start for uidNumbers, this number is added to the user.Pk to make sure that the numbers aren't too low for POSIX users. Default is 2000 to ensure that we don't collide with local users uidNumber</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>對於 uidNumbers 的起始值，這個數字會加到 user.Pk 上，以確保對於 POSIX 使用者來說，這個數字不會太低。預設值是 2000，以確保我們不會和本機使用者的 uidNumber 產生衝突</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5acb607b40356974">
<source>GID start number</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>GID 起始編號</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1c8e9816dcae6d9c">
<source>The start for gidNumbers, this number is added to a number generated from the group.Pk to make sure that the numbers aren't too low for POSIX groups. Default is 4000 to ensure that we don't collide with local groups or users primary groups gidNumber</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>對於 gidNumbers 的起始值，這個數字會加到從 group.Pk 生成的數字上，以確保對於 POSIX 群組來說，這個數字不會太低。預設值是 4000，以確保我們不會和本地群組或使用者的主要群組的 gidNumber 產生衝突</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2236dc563c2dbf76">
<source>(Format: hours=-1;minutes=-2;seconds=-3).</source>
<target>(格式： hours=-1;minutes=-2;seconds=-3).</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbec40ef4e6f139b7">
<source>(Format: hours=1;minutes=2;seconds=3).</source>
<target>(格式： hours=1;minutes=2;seconds=3).</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbb8ad22c83d375b1">
<source>The following keywords are supported:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>支援以下的關鍵字：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbb3243352661428f">
<source>Authentication flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分認證流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa72a3bd1e7e89926">
<source>Flow used when a user access this provider and is not authenticated.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者存取此供應商但未獲授權時的流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s62f7c59b0606a8d6">
<source>Authorization flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>授權流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfbaeb0de54fbfdbb">
<source>Flow used when authorizing this provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>授權此供應商時的流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc8de93a7dc0d78ba">
<source>Client type</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用戶端類型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s399cc2d67d92e957">
<source>Confidential</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>機密</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s95f09b229a0a0bb0">
<source>Confidential clients are capable of maintaining the confidentiality of their credentials such as client secrets</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>機密用戶端能夠維護其憑證的機密性，如：用戶端金鑰。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdd1ff479d04ac140">
<source>Public</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>公開</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s51c6b8403c2dc5d9">
<source>Public clients are incapable of maintaining the confidentiality and should use methods like PKCE. </source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>公開用戶端能夠使用如 PKCE 等方式維護其機密性。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4d00e5de1c8213b7">
<source>Client ID</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用戶端 ID</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s03fb3fa232f0434a">
<source>Client Secret</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用戶端金鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sde0ad51b14f77cf6">
<source>Redirect URIs/Origins (RegEx)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>重新導向到 URI 或 原始來源 (正規表示式)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7f9eb9c8bd26e8fd">
<source>Valid redirect URLs after a successful authorization flow. Also specify any origins here for Implicit flows.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功授權流程後的有效重新導向的網址。對於隱式流程，也在此處指定任何來源。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2a369bc2febb5d55">
<source>If no explicit redirect URIs are specified, the first successfully used redirect URI will be saved.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果未指定明確的重新導向 URI，將儲存第一個成功重新導向的 URI。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa8384c9c26731f83">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source>To allow any redirect URI, set this value to ".*". Be aware of the possible security implications this can have.</source>
<target>欲允許任何重新導向的 URI，輸入 ".*" ，但請注意這個可會有安全性風險。</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s55787f4dfcdce52b">
<source>Signing Key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>簽署金鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc6c57419ad3a01a8">
<source>Key used to sign the tokens.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於對權杖進行簽署的金鑰。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s124f93a61ee772d6">
<source>Advanced protocol settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>進階通訊協定設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s926e0ecf124fb01a">
<source>Access code validity</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>存取認證碼的有效性</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa578033f134a83b6">
<source>Configure how long access codes are valid for.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定存取認證碼的有效期限。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbea3db12fd799210">
<source>Access Token validity</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>存取權杖的有效性</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s72559845d38bf688">
<source>Configure how long access tokens are valid for.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定存取權杖的有效期限。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s821f6014c1a435b9">
<source>Refresh Token validity</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>重新整理權杖的有效性</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s00c2db16ea9bc263">
<source>Configure how long refresh tokens are valid for.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定重新整理權杖的有效期限。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2e3ef41a0edd8608">
<source>Scopes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>範疇</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3a3fae99373ce56b">
<source>Select which scopes can be used by the client. The client still has to specify the scope to access the data.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇用戶端可以使用的範疇，用戶端仍然需要指定範疇才能存取資料。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sffd2e553143d1b0e">
<source>Hold control/command to select multiple items.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>按住 ctrl/command 鍵選擇多個項目。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s26bf2730430efbea">
<source>Subject mode</source>
<target>Subject 模式</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sccc47f82044453f9">
<source>Based on the User's hashed ID</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於使用者雜湊 ID</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbd5be4fb7442a34c">
<source>Based on the User's ID</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於使用者 ID</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc9cf9ecaf9e5d67e">
<source>Based on the User's UUID</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於使用者 UUID</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4291727352c4f295">
<source>Based on the User's username</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於使用者名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd62cfc27ad4aa33b">
<source>Based on the User's Email</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於使用者的電子郵件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s55eb75bedf96be0f">
<source>This is recommended over the UPN mode.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這比 UPN 模式更推薦。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf80e9547166117e6">
<source>Based on the User's UPN</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於使用者的 UPN</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sde949d0ef44572eb">
<source>Requires the user to have a 'upn' attribute set, and falls back to hashed user ID. Use this mode only if you have different UPN and Mail domains.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>需要使用者設定了「upn」特徵項，備選將使用使用者雜湊 ID。只有您有不同的 UPN 和郵件網域時才使用本模式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9f23ed1799b4d49a">
<source>Configure what data should be used as unique User Identifier. For most cases, the default should be fine.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定應該使用哪些資料作為唯一的使用者識別碼。在大多數情況下使用預設值即可。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s17d1e337f6c11c1e">
<source>Include claims in id_token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在 id_token 中包含身分聲明</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbf41e0db12834133">
<source>Include User claims from scopes in the id_token, for applications that don't access the userinfo endpoint.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>對於那些不存取 userinfo 端點的應用程式，在 id_token 中將包含來自範疇的使用者身分聲明。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s850a58c683682809">
<source>Issuer mode</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>發行者模式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sde56783222b527d6">
<source>Each provider has a different issuer, based on the application slug</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於應用程式的縮寫，每個供應商都有一個不同的發行者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8d32d7b9e8ca60b1">
<source>Same identifier is used for all providers</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>所有供應商都使用相同的識別碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s37d9155b9f4cc7bd">
<source>Configure how the issuer field of the ID Token should be filled.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定該如何填寫 ID 權杖的發行者欄位。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se2adaf0371ffcd65">
<source>Machine-to-Machine authentication settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>機器對機器的認證設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s33318837e6c54a9b">
<source>Trusted OIDC Sources</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>受信任的 OIDC 來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s22e566052f7bec81">
<source>JWTs signed by certificates configured in the selected sources can be used to authenticate to this provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>透過所選來源中的憑證來簽署的 JWT ，可用於對此供應商進行身份認證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s072c6d12d3d37501">
<source>HTTP-Basic Username Key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>HTTP 基本認證的使用者金鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb2bb6f93773a4594">
<source>User/Group Attribute used for the user part of the HTTP-Basic Header. If not set, the user's Email address is used.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於 HTTP 基本認證標頭中，使用者區塊中的使用者/群組特徵項。如果未設定則套用使用者的電子郵件地址。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s70f6471de355b98c">
<source>HTTP-Basic Password Key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>HTTP 基本認證的密碼金鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf4de1644dcdb53d5">
<source>User/Group Attribute used for the password part of the HTTP-Basic Header.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於 HTTP 基本認證標頭中，密碼區塊中的使用者/群組特徵項。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb8dd788adf7b907b">
<source>Proxy</source>
<target>代理</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7489f76224f8120d">
<source>Forward auth (single application)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>轉發身分認證（單一應用程式）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s25d0cd75377daf75">
<source>Forward auth (domain level)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>轉發身分認證（網域級別）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s93574c03953f25dd">
<source>This provider will behave like a transparent reverse-proxy, except requests must be authenticated. If your upstream application uses HTTPS, make sure to connect to the outpost using HTTPS as well.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>此供應商將充當透明的反向代理，唯一的區別是請求必須通過身份認證。如果您的上游應用程式使用 HTTPS，請確保也使用 HTTPS 連接到 Outpost。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa29b5680cfafacc8">
<source>External host</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>外部主機</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s764bccb30868bf62">
<source>The external URL you'll access the application at. Include any non-standard port.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您欲存取應用程式的外部網址，包含任何非標準的連接埠。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scb317851cbcc6b12">
<source>Internal host</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>內部主機</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf05e384059a0a7c1">
<source>Upstream host that the requests are forwarded to.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>要求轉發到上游主機。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3d34068a31cab30b">
<source>Internal host SSL Validation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>內部主機的 SSL 驗證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4a26798e1c3c37dd">
<source>Validate SSL Certificates of upstream servers.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>驗證上游主機的 SSL 憑證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s44c90273f08fb718">
<source>Use this provider with nginx's auth_request or traefik's forwardAuth. Only a single provider is required per root domain. You can't do per-application authorization, but you don't have to create a provider for each application.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將此供應商與 nginx 的 auth_request 或 traefik 的 forwardAuth 一起使用。每個主網域只需要一個提供者。您無法執行每個應用程式的授權，但您不必為每個應用程式建立提供者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf55d28d4dff0e41b">
<source>An example setup can look like this:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定的範例如下：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb4a1d1c19438e929">
<source>authentik running on auth.example.com</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>authentik 運行於 auth.example.com</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s68f935c9ca792016">
<source>app1 running on app1.example.com</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>app1 運行於 app1.example.com</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf813a72d8fadd765">
<source>In this case, you'd set the Authentication URL to auth.example.com and Cookie domain to example.com.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在這種情況下，您需要將身分認證網址設定為 auth.example.com 並將 Cookie 的網域設定為 example.com。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s31d15c6f16951464">
<source>Authentication URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分認證網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa03fe48e892df2d8">
<source>The external URL you'll authenticate at. The authentik core server should be reachable under this URL.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您身分認證的外部網址，該網址應該要能夠連線到 authentik Core 伺服器。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7def067ed3ad3ad9">
<source>Cookie domain</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Cookie 網域</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s211b75e868072162">
<source>Set this to the domain you wish the authentication to be valid for. Must be a parent domain of the URL above. If you're running applications as app1.domain.tld, app2.domain.tld, set this to 'domain.tld'.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將此設定為用於使身分認證為有效的網域。必須是上述網址的上級網域。如果您的應用程式運行於 app1.domain.tld、app2.domain.tld 等等，則將其設定為「domain.tld」。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2345170f7e272668">
<source>Unknown proxy mode</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未知的代理模式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7c10976de6411844">
<source>Token validity</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖的有效性</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3e87ce98ba3c4d80">
<source>Configure how long tokens are valid for.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定權杖的有效期限。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd539548ca4c71619">
<source>Additional scopes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>額外的範疇</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8f12575f694e85a2">
<source>Additional scope mappings, which are passed to the proxy.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>額外範疇的對應，用於傳遞給代理服務。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s93cea6ca1f93349d">
<source>Unauthenticated URLs</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未經身分認證的網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc4508175bf6b09dd">
<source>Unauthenticated Paths</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未經身分認證的路徑</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc9fc206433f67588">
<source>Regular expressions for which authentication is not required. Each new line is interpreted as a new expression.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不需要身分認證的正規表示式，每一行區隔為新的表示式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd503fabef9691134">
<source>When using proxy or forward auth (single application) mode, the requested URL Path is checked against the regular expressions. When using forward auth (domain mode), the full requested URL including scheme and host is matched against the regular expressions.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當使用代理或轉發認證（單一應用程式）模式時，會根據正規表示式檢查要求的網址路徑。在使用轉發認證（網域模式）時，包含方案和主機在內的完整要求網址將與正規表示式進行配對。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb488dee0be434f7e">
<source>Authentication settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分認證設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s23cee624c735f266">
<source>Intercept header authentication</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>擷取標頭的身分認證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc007cca5af67eae0">
<source>When enabled, authentik will intercept the Authorization header to authenticate the request.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用時，authentik 將會擷取授權標頭來認證要求。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s36e630ba56617556">
<source>Send HTTP-Basic Authentication</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>傳送 HTTP 基本身分認證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9d5796a4b9b7560e">
<source>Send a custom HTTP-Basic Authentication header based on values from authentik.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>傳送一個基於 authentik 數值客製化的 HTTP 基本身分認證標頭。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s11204eeb1e27ea8f">
<source>ACS URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>ACS 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb7a30abc1dcf6c36">
<source>Issuer</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>發行者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf54c562d8a10ce77">
<source>Also known as EntityID.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>也稱為 EntityID。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s991b750e2d5c4234">
<source>Service Provider Binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>服務供應商附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd8f220c999726151">
<source>Redirect</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>重新導向</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb357ea19a722d827">
<source>Post</source>
<target>Post</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4e28e2899e08a5f8">
<source>Determines how authentik sends the response back to the Service Provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>決定 authentik 如何將回應送回給服務供應商。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd5a4b41c6c883b03">
<source>Audience</source>
<target>Audience</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc741d9ebe07ad103">
<source>Signing Certificate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>簽署憑證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd6c3ddb62de0e8f7">
<source>Certificate used to sign outgoing Responses going to the Service Provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於簽署外送回應給服務供應商的憑證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5be3b0567172e415">
<source>Verification Certificate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>驗證憑證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7c27e113f90a89e0">
<source>When selected, incoming assertion's Signatures will be validated against this certificate. To allow unsigned Requests, leave on default.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇時，傳入斷言的簽章將依據這個憑證進行認證。若要允許未簽署的要求，請表留預設值。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se6d950402810c34f">
<source>Property mappings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>屬性對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1a2797874b7fe852">
<source>NameID Property Mapping</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>nameID 屬性對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s256b8452664ccae4">
<source>Configure how the NameID value will be created. When left empty, the NameIDPolicy of the incoming request will be respected.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定如何建立 NameID 數值。如果為空則將遵守傳入要求的 NameIdPolicy。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9f91cc8bcfabb40f">
<source>Assertion valid not before</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>斷言的有效期限不早於</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s733f83ff9d50da30">
<source>Configure the maximum allowed time drift for an assertion.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定斷言的允許最大時間偏移量。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2af5754090898640">
<source>Assertion valid not on or after</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>斷言在這個的時間及之後無效：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s43c1f927936f0a02">
<source>Assertion not valid on or after current time + this value.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>斷言的有效期限為當前時間加上此值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sad8550b8731518d8">
<source>Session valid not on or after</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>會談在這個時間及之後無效：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0dd00fbaba08748a">
<source>Session not valid on or after current time + this value.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>會談的有效期限是當前時間加上此值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2a0f60e74b478804">
<source>Digest algorithm</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>摘要演算法</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s693d975d38ff0214">
<source>Signature algorithm</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>簽章演算法</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd1a5560fde6f2271">
<source>Successfully imported provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功匯入供應商。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s252a52330d32b900">
<source>Metadata</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>中繼資料</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7181a5504472e856">
<source>Apply changes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>套用變更</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5e8250fb85d64c23">
<source>Close</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>關閉</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sad59707375956ad2">
<source>Finish</source>
<target>完成</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc16e00a7a8b2fde2">
<source>Back</source>
<target>返回</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd5903cc8de68b3fc">
<source>No form found</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>找不到表單</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s45935843b1b5b496">
<source>Form didn't return a promise for submitting</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>表單提交時沒有回傳一個 promise 物件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s74475586afc1fb0f">
<source>Select type</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇類型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0b3bf19b31dd6bac">
<source>Try the new application wizard</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>試試看新的應用程式精靈</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa18e1c6e0e6f16cc">
<source>The new application wizard greatly simplifies the steps required to create applications and providers.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新的應用程式精靈大量簡化了建立應用程式和供應商的所需步驟。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s01ef54f5d7c6ed47">
<source>Try it now</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>立即嘗試</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s382a2aa3984474dd">
<source>Create</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s58d1eb482059da12">
<source>New provider</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新增供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa661ea7d7a50f2e9">
<source>Create a new provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立一個新的供應商。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5d6af4c100ad321b">
<source>Create <x id="0" equiv-text="${type.name}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立 <x id="0" equiv-text="${type.name}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb95baab425322600">
<source>Shared secret</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>共享密鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9e9316a6b0c16231">
<source>Client Networks</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用戶端網路</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7f2dcf01f7a8c0b7">
<source>List of CIDRs (comma-seperated) that clients can connect from. A more specific
CIDR will match before a looser one. Clients connecting from a non-specified CIDR
will be dropped.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用戶端可以連線的 CIDR 列表（以逗號分隔）。
更具體的 CIDR 會在較寬鬆的 CIDR 之前優先套用。
來自未指定 CIDR 的用戶端連線將被拒絕。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s61eacb19db252f5e">
<source>URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb21f33b039c86322">
<source>SCIM base url, usually ends in /v2.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SCIM 的基礎網址，通常以 /v2 結尾。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se68398e3c2c760b2">
<source>Token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s33ed903c210a6209">
<source>Token to authenticate with. Currently only bearer authentication is supported.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於身份認證的權杖，目前只支援 bearer 認證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfc8bb104e2c05af8">
<source>User filtering</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者篩選</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc0d0890fbd46ef62">
<source>Exclude service accounts</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>排除服務帳號</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s98b1cb8fb62909ec">
<source>Group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s23ab136ad85f0ad2">
<source>Only sync users within the selected group.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>只同步選中群組的使用者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfdedc3b0b2b7ce3d">
<source>Attribute mapping</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>特徵項對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saf794c74c9ea731e">
<source>User Property Mappings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者屬性對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s019555b5a442aa00">
<source>Property mappings used to user mapping.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於使用者對應的屬性對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7cb9aa9ee1783f00">
<source>Group Property Mappings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>群組屬性對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa319e3bf44c85963">
<source>Property mappings used to group creation.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於建立群組的屬性對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se09ab93d69f7f45b">
<source>Not used by any other object.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未被其他物件使用。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s10922bd0ac765562">
<source>object will be DELETED</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>物件將被刪除</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf3981f36525b0dbd">
<source>connection will be deleted</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>連線將被刪除</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s93cf77a59db53395">
<source>reference will be reset to default value</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>引用將被重設為預設值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3e211d29fa10f843">
<source>reference will be set to an empty value</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>引用將被設為空值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s55fa598b754cc3cc">
<source><x id="0" equiv-text="${ub.name}"/> (<x id="1" equiv-text="${consequence}"/>)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target><x id="0" equiv-text="${ub.name}"/> (<x id="1" equiv-text="${consequence}"/>)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s09240e07b5b8d640">
<source>ID</source>
<target>ID</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se33b158a1ec02a09">
<source>Successfully deleted <x id="0" equiv-text="${this.objects.length} ${this.objectLabel}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功刪除 <x id="0" equiv-text="${this.objects.length} ${this.objectLabel}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf6eb148db23d19de">
<source>Failed to delete <x id="0" equiv-text="${this.objectLabel}"/>: <x id="1" equiv-text="${e.toString()}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無法刪除 <x id="0" equiv-text="${this.objectLabel}"/>: <x id="1" equiv-text="${e.toString()}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s039b6434e8a75560">
<source>Delete <x id="0" equiv-text="${this.objectLabel}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>刪除 <x id="0" equiv-text="${this.objectLabel}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5819a49638f6d7cb">
<source>Are you sure you want to delete <x id="0" equiv-text="${this.objects.length} ${this.objectLabel}"/>?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您確定要刪除 <x id="0" equiv-text="${this.objects.length} ${this.objectLabel}"/>嗎？</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdc673e73b5c13aea">
<source>Delete</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>刪除</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb0b86b8ca6ab13bd">
<source>Providers</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3ffa320128991a45">
<source>Provide support for protocols like SAML and OAuth to assigned applications.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>為分配的應用程式提供如 SAML 和 OAuth 等協定的支援。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd2223afb7d6b100d">
<source>Type</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>類型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s10929ca568ae10bc">
<source>Provider(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb2b3b281954752c4">
<source>Assigned to application </source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分配給應用程式：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa6c0ba4910c7ad7f">
<source>Assigned to application (backchannel) </source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分配給應用程式（背景通道）：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s97f5e0c138eae172">
<source>Warning: Provider not assigned to any application.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：供應商未分配給任何應用程式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8b0432eecbd8b034">
<source>Update</source>
<target>更新</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc9175cb129fdc306">
<source>Update <x id="0" equiv-text="${item.verboseName}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新 <x id="0" equiv-text="${item.verboseName}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s398f6ba74ba8943a">
<source>Select providers to add to application</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇要加入到應用程式的供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf9aee319a006c9b4">
<source>Add</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>加入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa90b7809586c35ce">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source>Either input a full URL, a relative path, or use 'fa://fa-test' to use the Font Awesome icon "fa-test".</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>輸入完整網址、相對路徑，或者使用 'fa://fa-test' 來使用 Font Awesome 圖示 「fa-test」。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0410779cb47de312">
<source>Path template for users created. Use placeholders like `%(slug)s` to insert the source slug.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者建立的路徑範本，使用預置內容例如「%(slug)s」來插入來源縮寫。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s58fd2aafa4261c55">
<source>Successfully updated application.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新應用程式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9222ca30ae7786e4">
<source>Successfully created application.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立應用程式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s03907d7a66c6164e">
<source>Application's display Name.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式的顯示名稱。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s91f70424f5d5d23e">
<source>Slug</source>
<target>Slug</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdae55084f6cb2662">
<source>Optionally enter a group name. Applications with identical groups are shown grouped together.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可選：輸入群組名稱。具有相同群組的應用程式會排列在同一分組。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7f5869b3d14d7cbc">
<source>Provider</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s350a616ff5e145ec">
<source>Select a provider that this application should use.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇一個應用程式應該使用的供應商。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4c6534a118f52fdd">
<source>Select backchannel providers which augment the functionality of the main provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇背景通道供應商，以增強主要提供者的功能。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0639662111324466">
<source>Policy engine mode</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策引擎模式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1a0e95458b44d7f8">
<source>Any policy must match to grant access</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>必須符合任一政策才能取得存取權</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7fc1ace65486dc25">
<source>All policies must match to grant access</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>必須符合全部政策才能取得存取權</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8be4abc7ca71da6c">
<source>UI settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者介面設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s427f788ff333f45b">
<source>Launch URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟動的網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s992f8d1a776e763c">
<source>If left empty, authentik will try to extract the launch URL based on the selected provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果為空，authentik 將會嘗試從選擇的供應商取得啟動網址。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2348f46ebf436671">
<source>Open in new tab</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>另開新分頁</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8655c52824caac63">
<source>If checked, the launch URL will open in a new browser tab or window from the user's application library.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果勾選此項，將從使用者的應用程式庫中，在瀏覽器新的分頁或視窗中打開啟動的網址。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s068d4dd16d9106d0">
<source>Icon</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>圖示</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s67e20cd8018d7e3c">
<source>Currently set to:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>目前設定為：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s80e6d6fe5ad458d3">
<source>Clear icon</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>清除圖示</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6d3b4d0561ba1cff">
<source>Publisher</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>發行人</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa8c45b6b92a8ba1f">
<source>Create Application</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3d197283cb019b5a">
<source>Overview</source>
<target>概述</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6c3daaac4eed12f9">
<source>Changelog</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新日誌</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s05e395ff60af047b">
<source>Warning: Provider is not used by any Outpost.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：供應商未被任何 Outpost 使用。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sccbfc4dec0c8d80c">
<source>Assigned to application</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分配給應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2d46e3a9ee8e0e7e">
<source>Update LDAP Provider</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新 LDAP 供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s64ef2a6c2dd1d3d1">
<source>Edit</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>編輯</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saf24e253b3b006d4">
<source>How to connect</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如何連線</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s02b3fade1795d03f">
<source>Connect to the LDAP Server on port 389:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用連接埠 389 連線到 LDAP 伺服器：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa00cf67b54c44c71">
<source>Check the IP of the Kubernetes service, or</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查 Kubernetes 服務的 IP，或者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s28f270859c5f4d51">
<source>The Host IP of the docker host</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>docker 服務的主機 IP</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb7794c2910b1a9ec">
<source>Bind DN</source>
<target>Bind DN</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5694f9421c428227">
<source>Bind Password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Bind 密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s086e1bbe7c97ea16">
<source>Search base</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>搜尋基礎</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s417b90913e05bc17">
<source>Preview</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>預覽</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s17f3eaf3b07ece26">
<source>Warning: Provider is not used by an Application.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：供應商未被任何應用程式使用。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s56806e9f63efa298">
<source>Redirect URIs</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>重新導向 URI</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdbc08adee233f180">
<source>Update OAuth2 Provider</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新 OAuth2 供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9d96eb5ca93e6473">
<source>OpenID Configuration URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OpenID 設定網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s74f809a69e030351">
<source>OpenID Configuration Issuer</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OpenID 設定發行者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s028be8989873f001">
<source>Authorize URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>授權網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sebda1d54a3f9f967">
<source>Token URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2fc3eb68c7ced3af">
<source>Userinfo URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者資訊網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s145483489b87a622">
<source>Logout URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登出網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s59f5eda30a904b75">
<source>JWKS URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>JWKS 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s453b0c150a7ca58e">
<source>Example JWT payload (for currently authenticated user)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>範例 JWT 酬載（給目前已認證的使用者）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc6e8a34361c7c272">
<source>Forward auth (domain-level)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>轉發身分認證（網域級別）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6df42b3072a2d7e9">
<source>Nginx (Ingress)</source>
<target>Nginx (Ingress)</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8e01a852c1db8d29">
<source>Nginx (Proxy Manager)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Nginx Prxoxy Manager</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sabebdc7fa6a5bddb">
<source>Nginx (standalone)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Nginx (獨立應用程式)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5d9f93f1fe1c19d3">
<source>Traefik (Ingress)</source>
<target>Traefik (Ingress)</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se2b62f7e9017965e">
<source>Traefik (Compose)</source>
<target>Traefik (Compose)</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4c4c504a48c3b7bd">
<source>Traefik (Standalone)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Traefik (獨立應用程式)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7ba9677d069e5f02">
<source>Caddy (Standalone)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Caddy (獨立應用程式)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4a1e774ab25aa232">
<source>Internal Host</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>內部主機</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc9c3578cce3cf7a8">
<source>External Host</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>外部主機</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7a141f1b61074fbe">
<source>Basic-Auth</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基本身分認證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scb489a1a173ac3f0">
<source>Yes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>是</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s37cbecaec58e2192">
<source>Mode</source>
<target>模式</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4e474b9e2e737dd1">
<source>Update Proxy Provider</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新代理供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s37eb2f1b6e3c19c2">
<source>Protocol Settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通訊協定設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5116b89f7db1fbec">
<source>Allowed Redirect URIs</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>允許的重新導向 URI</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saeff3596e1ac31b6">
<source>Setup</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1b783856ab4aaaf3">
<source>No additional setup is required.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無須額外設定。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s09b671b120443043">
<source>Update Radius Provider</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新 Radius 供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd3386a2ef42e80b9">
<source>Download</source>
<target>下載</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf417c13d7a0f7995">
<source>Copy download URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>複製下載連結網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc1cfce89ebcf1bf9">
<source>Download signing certificate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>下載簽章憑證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2c0de3d35a7bc784">
<source>Related objects</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>有關聯的物件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s803b0621006085be">
<source>Update SAML Provider</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新 SAML 供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s44b1f042790cd1a2">
<source>SAML Configuration</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SAML 設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sba999428083abce3">
<source>EntityID/Issuer</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SEntityID/發行者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scd2984ee5552643a">
<source>SSO URL (Post)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SSO 網址（Post方法）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saa79b47f60c66458">
<source>SSO URL (Redirect)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SSO 網址（重新導向）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2da51a6287118ba8">
<source>SSO URL (IdP-initiated Login)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SSO 網址（識別提供者Idp發起的登入）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0a57e911e457302b">
<source>SLO URL (Post)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SLO 網址（Post方法）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1e7308bb1ca323e1">
<source>SLO URL (Redirect)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SLO 網址（重新導向）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd2c58d7c6dddc515">
<source>SAML Metadata</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SAML 中繼資料</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s382b702673776873">
<source>Example SAML attributes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SAML 的特徵項範例</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sea3bfc143ced73db">
<source>NameID attribute</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>NameID 特徵項</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2f0f6691de0b0388">
<source>Warning: Provider is not assigned to an application as backchannel provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：供應商未作為背景通道分配給任何應用程式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc6c575c5ff64cdb1">
<source>Update SCIM Provider</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新 SCIM 供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7da38af36522ff6a">
<source>Sync not run yet.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>尚未執行同步。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbecf8dc03c978d15">
<source>Run sync again</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>再次執行同步</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc2cedfb22488ccb2">
<source>Modern applications, APIs and Single-page applications.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新一代的應用程式，API 和單頁式應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc3259eb55cf91e8c">
<source>LDAP</source>
<target>LDAP</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sffd5481034a1bd41">
<source>Provide an LDAP interface for applications and users to authenticate against.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>提供一個 LDAP 介面，供應用程式和用戶進行身份認證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0c9670f429e74283">
<source>New application</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新增應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6ba50bb0842ba1e2">
<source>Applications</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s96b2fefc550e4b1c">
<source>Provider Type</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>供應商類型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd20f6cd02c90867f">
<source>Application(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb564f81eb057342e">
<source>Application Icon</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式圖示</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa347e31efbb60be2">
<source>Update Application</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd9b556a84ae25690">
<source>Successfully sent test-request.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功發送測試要求。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5deac600e329de1b">
<source>Log messages</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>日誌訊息</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3feea7b49673bef2">
<source>No log messages.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無日誌訊息。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa45a194b58837e4f">
<source>Active</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s58c867aac77b9158">
<source>Last login</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最近登入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3e3bb9e7cb1de4fd">
<source>Select users to add</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇要加入的使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s75d5ff5dd8d3c6d2">
<source>Successfully updated group.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新群組。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3079ca1184e77573">
<source>Successfully created group.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立群組。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s63cb05541b294335">
<source>Is superuser</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成為超級使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s29315e374008d0c5">
<source>Users added to this group will be superusers.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>加入到該群組的成員將會成為超級使用者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4eb514ebcb80553d">
<source>Parent</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>上級群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s16b9446e3a70e1f4">
<source>Attributes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>特徵項</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sec97cdaf7af8648b">
<source>Set custom attributes using YAML or JSON.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用 YAML 或 JSON 設定客製化特徵項。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1e36813d3504ed48">
<source>Successfully updated binding.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新附加。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1bf56ee106e9e711">
<source>Successfully created binding.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立附加。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s042baf59902a711f">
<source>Policy</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5f5bf4ef2bd93c04">
<source>Group mappings can only be checked if a user is already logged in when trying to access this source.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>僅當已登入的使用者在存取此來源時，才能檢查群組對應。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6c607d74bdfe9f36">
<source>User mappings can only be checked if a user is already logged in when trying to access this source.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>僅當已登入的使用者在存取此來源時，才能檢查使用者對應。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s965c503c3e42fdfe">
<source>Enabled</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用中</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6b85380416964890">
<source>Negate result</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>反向结果</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3bfa0258999fb629">
<source>Negates the outcome of the binding. Messages are unaffected.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>反轉附加的結果。訊息不受影響。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2ba5f4d8f3bd7c57">
<source>Order</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>執行順序</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se1e040b55319a0e8">
<source>Timeout</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>逾時過期</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s29ec5e7889f4787f">
<source>Successfully updated policy.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新政策。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfc400b2d71e49d28">
<source>Successfully created policy.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立政策。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="safc0e0656d572f4e">
<source>A policy used for testing. Always returns the same result as specified below after waiting a random duration.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於測試的政策。等待隨機的時間後回傳相同的結果。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9ffa1ac03ce6fd20">
<source>Execution logging</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>執行的日誌紀錄</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saf31b3c610036ed6">
<source>When this option is enabled, all executions of this policy will be logged. By default, only execution errors are logged.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用此選項時，將會記錄這個政策所有的日誌。預設只會記錄錯誤日誌。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa879d5ce584875cf">
<source>Policy-specific settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策詳細設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s838418d1a0815157">
<source>Pass policy?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策通過？</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd8c5339b82b71507">
<source>Wait (min)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>等待時間 (最短)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sda4e78c19f5b6f35">
<source>The policy takes a random time to execute. This controls the minimum time it will take.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策需要一段隨機時間才能執行。這個設定控制最短等待時間。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1d30ff9ba938e68d">
<source>Wait (max)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>等待時間 (最長)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s303b5e552246e613">
<source>Matches an event against a set of criteria. If any of the configured values match, the policy passes.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>根據一系列標準配對事件。如果符合任何設定的數值，則政策通過。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s890810efbe103cbc">
<source>Match created events with this action type. When left empty, all action types will be matched.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將此動作類型與建立的事件配對。如果為空則將符合所有動作類型。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfab527528ea64618">
<source>Matches Event's Client IP (strict matching, for network matching use an Expression Policy.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>配對事件的用戶端 IP（嚴格篩選，如要配對網路請使用表示式政策）。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5a15a8f39c699273">
<source>Match events created by selected application. When left empty, all applications are matched.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將選擇的應用程式與建立的事件配對。如果為空則將符合所有應用程式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5a13f4bbe004503f">
<source>Checks if the request's user's password has been changed in the last x days, and denys based on settings.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查要求中的使用者密碼在過去幾個天內是否已更改，並根據設定決定是否拒絕。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfad8af8ce38104a3">
<source>Maximum age (in days)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最長有效期限（以天為單位）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9307f3dbb07a73b5">
<source>Only fail the policy, don't invalidate user's password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>僅不通過政策，不取消使用者密碼的有效性</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scea1f16238093e35">
<source>Executes the python snippet to determine whether to allow or deny a request.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>執行 Python 程式片段以決定是否允許或拒絕要求。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sabd1bc9fb7da71e7">
<source>Expression using Python.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用 Python 的表示式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8d08843f397d9e81">
<source>See documentation for a list of all variables.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>有關所有變數列表請參考官方文件。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se2cc93bd2647baec">
<source>Static rules</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>靜態規則</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc96dd9d2e7b05fc5">
<source>Minimum length</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最短密碼長度</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s33d48fb745f4d4ae">
<source>Minimum amount of Uppercase Characters</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最少大寫字母數量</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s883b544e2b4aa3b5">
<source>Minimum amount of Lowercase Characters</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最少小寫字母數量</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s43be3ce2439ffe9c">
<source>Minimum amount of Digits</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最少數字數量</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb3651834cca86735">
<source>Minimum amount of Symbols Characters</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最少特殊符號數量</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc2f116c0ea77d58a">
<source>Error message</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>錯誤訊息</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s21d0e290c51a8ef9">
<source>Symbol charset</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>特殊符號字元編碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s545d99afa61e4095">
<source>Characters which are considered as symbols.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將被視為特殊符號的字元。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1293ad87acc7a609">
<source>HaveIBeenPwned settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>HaveIBeenPwned 設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdf4e1c6a2f072600">
<source>Allowed count</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可允許的次數</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scd8062ff5e1326d8">
<source>Allow up to N occurrences in the HIBP database.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>允許出現在 HIBP 資料庫的次數。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3fd219b045193507">
<source>zxcvbn settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>zxcvbn 設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s28d84abfbaf555ea">
<source>Score threshold</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分數閾值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7b3148ffba9f4527">
<source>If the password's score is less than or equal this value, the policy will fail.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果密碼的分數不大於此數值，則未通過政策。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd6cd7ce2310a73a4">
<source>Checks the value from the policy request against several rules, mostly used to ensure password strength.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>依據多條規則來檢查政策要求中的值，主要用於確保密碼強度。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2a957e843960b604">
<source>Password field</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>密碼欄位的鍵值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se8a81c75b6e30a33">
<source>Field key to check, field keys defined in Prompt stages are available.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>要檢查的鍵值，欄位鍵值可在提示階段中選取。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2f8c4cf12350a36c">
<source>Check static rules</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查靜態規則</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd75a9a71309fb387">
<source>Check haveibeenpwned.com</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查 haveibeenpwned.com</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se5cb18408df3284e">
<source>For more info see:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>若要更多資訊請前往：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scef7abb8456b06d6">
<source>Check zxcvbn</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查 zxcvbn</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdfdb58cd232b363d">
<source>Password strength estimator created by Dropbox, see:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>由 Dropbox 建立的密碼強度指示計，請前往：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s40b034801fcb843b">
<source>Allows/denys requests based on the users and/or the IPs reputation.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>根據使用者或 IP 名譽來允許或禁止要求。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scf4afecb0f1e69b2">
<source>Invalid login attempts will decrease the score for the client's IP, and the
username they are attempting to login as, by one.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無效的登入嘗試將使該用戶端 IP 和該使用者名稱的分數每次減少1分。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8323a9af28e10502">
<source>The policy passes when the reputation score is below the threshold, and
doesn't pass when either or both of the selected options are equal or above the threshold.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當名譽分數低於閾值時能通過政策。反之，當選項中的任何一個以上等於或高於閾值時，不通過政策。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1828fbfc2c56379c">
<source>Check IP</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查 IP</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4751df77cfd8a5f9">
<source>Check Username</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查使用者名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se19cc57dd8675498">
<source>Threshold</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>閾值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdbccb39a658f0e45">
<source>New policy</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新增政策</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf693300708a40d2c">
<source>Create a new policy.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立一個新的政策。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5b1fb0d4c0daeba8">
<source>Create Binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9fb28be12e2c6317">
<source>Superuser</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>超級使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9f5a5f23312798f0">
<source>Members</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成員</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7eb3d239e0b491ab">
<source>Select groups to add user to</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇要加入使用者的群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sec5cdfa358f9dbf7">
<source>Warning: Adding the user to the selected group(s) will give them superuser permissions.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：使用者加入到所選的群組將會賦予其超級使用者的權限。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scab2900019953050">
<source>Successfully updated user.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新使用者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9c3c272944dcfca3">
<source>Successfully created user.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立使用者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s03f42eea72154959">
<source>Username</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5a802e46a033c8af">
<source>User's primary identifier. 150 characters or fewer.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者的主要識別碼。150個字元以內。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd34be0d0fcb39971">
<source>User's display name.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用使用者的顯示名稱。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd1f44f1a8bc20e67">
<source>Email</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>電子郵件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbe3b416a356f1c91">
<source>Is active</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用帳戶</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s35fac2e5677d55cd">
<source>Designates whether this user should be treated as active. Unselect this instead of deleting accounts.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>決定是否將此使用者視為啟用的帳戶。建議取消選擇此項來停用，而不是刪除帳戶。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2e532e19ed477a56">
<source>Path</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>路徑</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s67560d7e37d984c3">
<source>Policy / User / Group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策 / 使用者 / 群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s030ac0829bb50a49">
<source>Policy <x id="0" equiv-text="${item.policyObj?.name}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策 <x id="0" equiv-text="${item.policyObj?.name}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2a64d2dca3da9b0e">
<source>Group <x id="0" equiv-text="${item.groupObj?.name}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>群組 <x id="0" equiv-text="${item.groupObj?.name}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se5dc026819a32ff8">
<source>User <x id="0" equiv-text="${item.userObj?.name}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者 <x id="0" equiv-text="${item.userObj?.name}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s50c312bea93b6925">
<source>Edit Policy</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>編輯政策</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0b55a57f473ab8af">
<source>Update Group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s494e1ed913d9351a">
<source>Edit Group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>編輯群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sad130c2d925fb7bf">
<source>Update User</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5cd31f4a88adf180">
<source>Edit User</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>編輯使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se291dfd2a59d7842">
<source>Policy binding(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7e87ab366c199345">
<source>Update Binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s40b80eb4cc1f0e0c">
<source>Edit Binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>編輯附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbad5b96fb855ef36">
<source>No Policies bound.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>沒有已附加的政策。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc15d60377cc8aaac">
<source>No policies are currently bound to this object.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>目前沒有附加到此物件的政策。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sddb040c47daae56b">
<source>Bind existing policy</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>附加到現存的政策</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saa855c61e0403fe6">
<source>Warning: Application is not used by any Outpost.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：應用程式未被任何 Outpost 使用。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb6cbd4f92ebaf5d8">
<source>Related</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>關聯</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc92ea8fbf9ba06a7">
<source>Backchannel Providers</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>背景通道供應商</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd71081c23d1cd38b">
<source>Check access</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查存取權限</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s42cbd8dca939a9c7">
<source>Check</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf22f7f8a9309b4ed">
<source>Check Application access</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查應用程式存取權限</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2474e7fb1aec9f05">
<source>Test</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>測試</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s512957aa09384646">
<source>Launch</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟動</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sed02f831e653deb3">
<source>Logins over the last week (per 8 hours)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>一周的登入狀態(每 8 小時)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2b1bc31276c4c477">
<source>Policy / Group / User Bindings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策 / 使用者 / 群組 附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s473f0143efa3f706">
<source>These policies control which users can access this application.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這些政策控制了哪些使用者可以存取這個應用程式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s24875d5475e82526">
<source>Successfully updated source.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新來源。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s60d891ed3ee9ebc5">
<source>Successfully created source.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立來源。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8af7239354f7e7b6">
<source>Sync users</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>同步使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd80b0b8aeae3abe3">
<source>User password writeback</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可改寫使用者密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2b952e9dc99cbded">
<source>Login password is synced from LDAP into authentik automatically. Enable this option only to write password changes in authentik back to LDAP.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登入密碼會自動從 LDAP 同步到 authentik。啟用此選項可將 authentik 修改的密碼同步回 LDAP。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saf7ce4165a1025f6">
<source>Sync groups</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>同步群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2035f889f576bca6">
<source>Connection settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>連線設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0a72e65aef45b1e8">
<source>Server URI</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>伺服器 URI</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa599dbe5776897ad">
<source>Specify multiple server URIs by separating them with a comma.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>若要新增多個伺服器，透過逗號分隔多個伺服器 URI。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se36b55dfcf5dc80b">
<source>Enable StartTLS</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用 StartTLS</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s33683c3b1dbaf264">
<source>To use SSL instead, use 'ldaps://' and disable this option.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>若要使用 SSL 請停用此選項，並使用「ldaps://」。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2221fef80f4753a2">
<source>TLS Verification Certificate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>TLS 驗證憑證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb8c13bd58191cea2">
<source>When connecting to an LDAP Server with TLS, certificates are not checked by default. Specify a keypair to validate the remote certificate.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用 TLS 連線到 LDAP 時，預設不檢查憑證，選擇金鑰對來驗證遠端憑證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb7684e2910a33a1f">
<source>Bind CN</source>
<target>Bind CN</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3de6db803012016a">
<source>LDAP Attribute mapping</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>LDAP 特徵碼對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7c05ee41d634aa45">
<source>Property mappings used to user creation.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於建立使用者的屬性對應。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s94333971a07803b9">
<source>Additional settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>其他設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd14a19a19d507f9e">
<source>Parent group for all the groups imported from LDAP.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>從 LDAP 匯入群組的上級群組。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfbc59ff17a73503d">
<source>User path</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者路徑</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd18170637295bace">
<source>Addition User DN</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>額外的使用者 DN</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9ae089fd248e72db">
<source>Additional user DN, prepended to the Base DN.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>額外的使用者 DN，將優先於 Base DN。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5944355d69db1fb8">
<source>Addition Group DN</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>額外的群組 DN</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfae9f4ea5749a36b">
<source>Additional group DN, prepended to the Base DN.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>額外的群組 DN，將優先於 Base DN。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s66ffc06300964849">
<source>User object filter</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者物件篩選器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1c2a173db0e1ec61">
<source>Consider Objects matching this filter to be Users.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>符合此篩選的物件將視為使用者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2ec94a7c7f5bcd1b">
<source>Group object filter</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>群組物件篩選器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saf5eb7596b3a355b">
<source>Consider Objects matching this filter to be Groups.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>符合此篩選的物件將視為群組。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf325a4adba4d6278">
<source>Group membership field</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>群組成員欄位</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s76768bebabb7d543">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source>Field which contains members of a group. Note that if using the "memberUid" field, the value is assumed to contain a relative distinguished name. e.g. 'memberUid=some-user' instead of 'memberUid=cn=some-user,ou=groups,...'</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>包含群組成員的欄位。注意，如果使用「memberUid」欄位，則假設其值包含相對可分辨的名稱。例如，「memberUID=some-user」而不是「memberuid=cn=some-user,ou=groups,... 」</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s026555347e589f0e">
<source>Object uniqueness field</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>物件的唯一性欄位</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s24211f319e5b7e98">
<source>Field which contains a unique Identifier.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>包含唯一識別碼的欄位。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s900b0d85b872d134">
<source>Link users on unique identifier</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用唯一識別碼連結使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6c70a73265e14521">
<source>Link to a user with identical email address. Can have security implications when a source doesn't validate email addresses</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>連結到具有相同電子郵件地址的使用者。當來源不驗證電子郵件地址時，可能會有安全風險。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s995535e7af30d754">
<source>Use the user's email address, but deny enrollment when the email address already exists</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用使用者的電子郵件地址，但在電子郵件地址已存在時拒絕註冊。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s542ecb4130f6cea5">
<source>Link to a user with identical username. Can have security implications when a username is used with another source</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>連接到具有相同使用者名稱的使用者。當使用者名稱與其他來源一同使用時，可能會有安全風險。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2a1debf34e5aeba4">
<source>Use the user's username, but deny enrollment when the username already exists</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用使用者的使用者名稱，但在使用者名稱已存在時拒絕註冊。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s81ce0d54727f42d2">
<source>Unknown user matching mode</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未知使用者配對模式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd04376c4216c921f">
<source>URL settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>網址設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s872d0e88ab34ed83">
<source>Authorization URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>授權網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="see3ff55262fd6500">
<source>URL the user is redirect to to consent the authorization.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者被重新導向到此網址以同意授權。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb932dead79567c7b">
<source>Access token URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>存取權杖網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s88b8a2892635a2fc">
<source>URL used by authentik to retrieve tokens.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>authentik 用來擷取權杖的網址。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s69bd313dd12fc2f3">
<source>Profile URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>個人資訊網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa8d83cd8023e8e4d">
<source>URL used by authentik to get user information.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>authentik 用來擷取個人資訊的網址。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc7707b3ba3a2a7ca">
<source>Request token URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>要求權杖網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3926da5b20cdf3b6">
<source>URL used to request the initial token. This URL is only required for OAuth 1.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於要求初始權杖的網址，僅用於 OAuth 1。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s199b55513a739f43">
<source>OIDC Well-known URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OIDC Well-known 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8b149b30b5b523ef">
<source>OIDC well-known configuration URL. Can be used to automatically configure the URLs above.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OIDC Well-known 設定的網址。可以用於自動設定以上網址。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9db2c836ade1339c">
<source>OIDC JWKS URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OIDC JWKS 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4b2a1b657c160f5b">
<source>JSON Web Key URL. Keys from the URL will be used to validate JWTs from this source.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>JSON 網路金鑰的網址。才該網址擷取的金鑰用於驗證此來源的 JWT。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2df0b65125600de9">
<source>OIDC JWKS</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OIDC JWKS</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s02de8d9e8583b480">
<source>Raw JWKS data.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>原始 JWKS 資料。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s81a87652ade099e4">
<source>User matching mode</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用戶配對模式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s485c05d34eb00415">
<source>Delete currently set icon.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>刪除目前的圖示。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se8987bdfb35e46b2">
<source>Consumer key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>客戶金鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sabaf0061f7e41b0b">
<source>Consumer secret</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>客戶機密密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa61966cd83b4924c">
<source>Additional scopes to be passed to the OAuth Provider, separated by space. To replace existing scopes, prefix with *.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>額外的範疇將傳遞給 OAuth 供應商，用空格分隔。要替換現存範疇，請在前面加上 *。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1cc0e66dbd2b5502">
<source>Flow settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>流程設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfe6977a3aea3ee6e">
<source>Flow to use when authenticating existing users.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>認證現存使用者的流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2801a48ceac691b3">
<source>Enrollment flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>註冊流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5d0a14d29ebad561">
<source>Flow to use when enrolling new users.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新使用者註冊時的流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s91f389c796720a81">
<source>Load servers</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>載入伺服器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s24f405197ede5ebb">
<source>Re-authenticate with plex</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用 plex 重新身分認證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc297b2e13c28ecf9">
<source>Allow friends to authenticate via Plex, even if you don't share any servers</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>允許好友通過 Plex 進行身分認證，即便您沒有分享任何伺服器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfee91e08b8b47477">
<source>Allowed servers</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>允許的伺服器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s216eb300543edd91">
<source>Select which server a user has to be a member of to be allowed to authenticate.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇使用者必須是其成員才能被允許進行身份認證的伺服器。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s31d7f3ba04d306a5">
<source>SSO URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SSO 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1d9d6c5b424fdc1f">
<source>URL that the initial Login request is sent to.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>第一次登入要求發送的網址。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd94db2b8c85d10a6">
<source>SLO URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SLO 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc764ddf60b5149de">
<source>Optional URL if the IDP supports Single-Logout.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分識別提供者 Idp 如果支援單一登出時的可選網址。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se7430794fa89005a">
<source>Also known as Entity ID. Defaults the Metadata URL.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>也稱為 Entity ID，預設為中繼資料的網址。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5615bb595ad6ded6">
<source>Binding Type</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>附加類型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa2e4d6830226d3ec">
<source>Redirect binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>重新導向附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6f96a78d81ef277c">
<source>Post-auto binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>自動 Post 附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc2c70fd56f5d0b48">
<source>Post binding but the request is automatically sent and the user doesn't have to confirm.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Post 附加，但自動傳送要求，使用者無需確認。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s968c90258dcf7562">
<source>Post binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Post 附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se10bbf4cf861c81b">
<source>Signing keypair</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>簽署的金鑰對</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s838ed611b533b19e">
<source>Keypair which is used to sign outgoing requests. Leave empty to disable signing.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於簽署傳出要求的金鑰對。保持為空停用簽署。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s39c8c0bf4d927c9f">
<source> Allow IDP-initiated logins</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>允許識別提供者 Idp 發起的登入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s65d507f1513c2f03">
<source>Allows authentication flows initiated by the IdP. This can be a security risk, as no validation of the request ID is done.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>允許由身份提供者 Idp 發起的認證流程。這可能是一個安全風險，因為不會驗證要求的 ID。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s297a2075bd7e40db">
<source>NameID Policy</source>
<target>NameID 政策</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s004e9a2c90f23900">
<source>Persistent</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>持久性</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s38887b94b3320533">
<source>Email address</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>電子郵件地址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2d34c87f67f66c6a">
<source>Windows</source>
<target>Windows</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1665454e31e14941">
<source>X509 Subject</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>X509 主體</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0c3ac7f9383a8cfd">
<source>Transient</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>暫時性</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s20a0ce62823bfa97">
<source>Delete temporary users after</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在此之後刪除臨時使用者：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3198c384c2f68b08">
<source>Time offset when temporary users should be deleted. This only applies if your IDP uses the NameID Format 'transient', and the user doesn't log out manually.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>刪除臨時使用者的時間偏移量。這僅適用於您的身份提供者使用 NameID 格式「transient」，且用戶沒有手動登出的情況。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb32e9c1faa0b8673">
<source>Pre-authentication flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分認證前的流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa3c1f6ac5e63a70f">
<source>Flow used before authentication.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在身分認證前使用的流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se12969ade44cd2b6">
<source>New source</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新增身分來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s19b09f4fc72175d1">
<source>Create a new source.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立一個新的身分來源。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6152026c364ad974">
<source>Sources of identities, which can either be synced into authentik's database, or can be used by users to authenticate and enroll themselves.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分來源，既可以同步到 authentik 的資料庫，也能被使用者用來進行身分認證和註冊。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0a0ca63b967f1630">
<source>Source(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s66722bc2ea775e05">
<source>Disabled</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已停用</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4ff2c202b4e5bdc5">
<source>Built-in</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>內建</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s52b500138a2d2b8a">
<source>Update LDAP Source</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新 LDAP 來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s31a2d43bc1cf1790">
<source>Not synced yet.</source>
<target>尚未同步。</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s388ee787bbf2271b">
<source>Task finished with warnings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>工作完成，但出現警告</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s949826fad0fe0909">
<source>Task finished with errors</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>工作完成，但出現錯誤</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbedb77365a066648">
<source>Last sync: <x id="0" equiv-text="${task.taskFinishTimestamp.toLocaleString()}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>上次同步： <x id="0" equiv-text="${task.taskFinishTimestamp.toLocaleString()}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf3fec8353106ac2f">
<source>OAuth Source <x id="0" equiv-text="${this.source.name}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OAuth 來源 <x id="0" equiv-text="${this.source.name}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se09d055771f3a11d">
<source>Generic OpenID Connect</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通用 OpenID 連線</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5c1dc164c89ac13e">
<source>Unknown provider type</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未知的供應商類型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s355b21b89ce5d9c5">
<source>Details</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>詳細資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s01088b6625d2443b">
<source>Callback URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>回呼網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb6d5146d5efb3058">
<source>Access Key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>存取金鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s065604a41e9d1584">
<source>Update OAuth Source</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新 OAuth 來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7b576aa71acb36a6">
<source>Diagram</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>示意圖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s587ba266269297ab">
<source>Policy Bindings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2feae323f46479f8">
<source>These bindings control which users can access this source.
You can only use policies here as access is checked before the user is authenticated.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這些附加控制哪些使用者可以存取此來源。因為在使用者身份認證之前就會檢查存取權限，所以這裡只能使用政策。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se17fcb1f159ee382">
<source>Update Plex Source</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新 Plex 來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saa10777250a6deca">
<source>Update SAML Source</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新 SAML 來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s643d8f2e5e5e930d">
<source>Successfully updated mapping.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新對應。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sffeef5b119d8625c">
<source>Successfully created mapping.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立對應。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1c33d22492029aba">
<source>Object field</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>物件欄位</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s06df3c3b6a503da8">
<source>Field of the user object this value is written to.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>此值寫入到使用者物件的欄位。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd39c5e998efecf93">
<source>SAML Attribute Name</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SAML 特徵項名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scf2790cf3ad89283">
<source>Attribute name used for SAML Assertions. Can be a URN OID, a schema reference, or a any other string. If this property mapping is used for NameID Property, this field is discarded.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於 SAML 斷言的特徵項名稱。可以是 URN OID，綱要參考或任何其他字串。如果此屬性對應用於 NameID 屬性，則此欄位將被忽略。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sab6d24c5ec8dc361">
<source>Friendly Name</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>易記名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9f8aac89fe318acc">
<source>Optionally set the 'FriendlyName' value of the Assertion attribute.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可選：設定斷言特徵項中的「FriendlyName」值。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s851c108679653d2a">
<source>Scope name</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>範疇名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s23fd4411419fca06">
<source>Scope which the client can specify to access these properties.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用戶端可以指定存取這些屬性的範疇。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7754f0e34f27fb6e">
<source>Description shown to the user when consenting. If left empty, the user won't be informed.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當需要使用者同意時顯示的說明。如果留空將不會顯示。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb6c3bf5489d7556e">
<source>Example context data</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>範例上下文資料</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4a697f0b36c4fe83">
<source>Active Directory User</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Active Directory 使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9277b90db38e1983">
<source>Active Directory Group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Active Directory 群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc2e03590269d5a10">
<source>New property mapping</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新增屬性對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s713e8666ed70f8b3">
<source>Create a new property mapping.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立一個新的屬性對應。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sce106606ae84d46f">
<source>Property Mappings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>屬性對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s271a7e04ff9865b1">
<source>Control how authentik exposes and interprets information.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>控制 authentik 如何公開和解釋資訊。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s59dc0eda07f9e2b6">
<source>Property Mapping(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>屬性對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa57c393736e2732c">
<source>Test Property Mapping</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>測試屬性對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc39fb3ff3753d5ab">
<source>Hide managed mappings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>隱藏代管對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s476ffc07e6d66f18">
<source>Successfully updated token.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新權杖。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s93c1e5fbe8184895">
<source>Successfully created token.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立權杖。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5fc4269c2addee61">
<source>Unique identifier the token is referenced by.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖參考的唯一識別碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb8bc2b8376c96a6b">
<source>Intent</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用目的</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbd34d118bcb1aaf2">
<source>API Token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>API 權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se31d92bea7f3a186">
<source>Used to access the API programmatically</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於程式化存取 API</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfd586951c75eb291">
<source>App password.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s59bf194136d0d13a">
<source>Used to login using a flow executor</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用流程執行器來進行登入。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1b14062c44e5ef45">
<source>Expiring</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>是否會過期</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="safcc54b2aedb1a17">
<source>If this is selected, the token will expire. Upon expiration, the token will be rotated.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當啟用時，權杖將會過期。在過期後權杖將會被輪替。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4165cd175bc4c0c4">
<source>Expires on</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>有效期限</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1cd198d689c66e4b">
<source>API Access</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>API 存取權限</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf29883ac9ec43085">
<source>App password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfe211545fd02f73e">
<source>Verification</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>驗證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd73b202ec04eefd9">
<source>Unknown intent</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未知使用目的</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s78fd8c03f8c967f3">
<source>Tokens</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdcc7b2c109ce9775">
<source>Tokens are used throughout authentik for Email validation stages, Recovery keys and API access.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖在整個 authentik 中用於電子郵件認證階段、救援金鑰和存取 API。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf71dba2c30283a54">
<source>Expires?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>是否會過期</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc7be80a7f8ec597e">
<source>Expiry date</source>
<target>到期日</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s71dcd9cf808449aa">
<source>Token(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb15e8daacf26bdfc">
<source>Create Token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8d7ecd944ebe834b">
<source>Token is managed by authentik.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>由 authentik 管理的權杖。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd1288ca57e221cf9">
<source>Update Token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0af6301e76e2a2a5">
<source>Successfully updated tenant.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新租户。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf55c7c06dbc2c8c6">
<source>Successfully created tenant.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立租戶。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s41706a202b6c40f1">
<source>Domain</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>網域</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se74ce42d41e392ba">
<source>Matching is done based on domain suffix, so if you enter domain.tld, foo.domain.tld will still match.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>由網域的後輟配對，如果您输入 domain.tld，foo.domain.tld 仍將會符合。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s11326fd2590f4e5e">
<source>Default</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設為預設</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se1c85959463f53df">
<source>Use this tenant for each domain that doesn't have a dedicated tenant.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>對於每個沒有專有租戶的網域，請使用此租戶。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc19838ca8c135c1b">
<source>Branding settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>品牌設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s99f110d27e30b289">
<source>Title</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>標題</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sab6bad52985c6676">
<source>Branding shown in page title and several other places.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>品牌訊息會顯示在頁面標題和其他地方。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4f1af2b48a5e249a">
<source>Logo</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>品牌標誌</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd6b8b4156f7df696">
<source>Icon shown in sidebar/header and flow executor.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在側邊欄、標題和流程執行器中顯示的圖示。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3626433940124897">
<source>Favicon</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>網站圖示</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se99efc0873031976">
<source>Icon shown in the browser tab.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>瀏覽器頁籤上顯示的圖示。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s10356fd921037fbf">
<source>Default flows</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>預設流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd216b08bafb297ee">
<source>Flow used to authenticate users. If left empty, the first applicable flow sorted by the slug is used.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於對使用者進行身分認證的流程。如果為空則按縮寫順序使用第一個符合的流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s35e6e60e83a8c003">
<source>Invalidation flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登出流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7989db5f4819af89">
<source>Flow used to logout. If left empty, the first applicable flow sorted by the slug is used.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於登出的流程。如果為空則按縮寫順序使用第一個符合的流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfeb779d4ccbc5a0e">
<source>Recovery flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>救援流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1c2fd8097e14a608">
<source>Recovery flow. If left empty, the first applicable flow sorted by the slug is used.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於各類救援的流程。如果為空則按縮寫順序使用第一個符合的流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s836aa192b30c21da">
<source>Unenrollment flow</source>
<target>取消注册流程</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s081d3c4b47a6ff83">
<source>If set, users are able to unenroll themselves using this flow. If no flow is set, option is not shown.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果設定此欄位，使用者可使用這個流程自行刪除自己的帳號。如果為空則不顯示選項。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="secbfd13bdae95a59">
<source>User settings flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者設定流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s523160b433311521">
<source>If set, users are able to configure details of their profile.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果設定此欄位，使用者可以修改他們的個人資訊。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s134177568525dbc8">
<source>Device code flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>裝置認證碼流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7b298427bdea81ae">
<source>If set, the OAuth Device Code profile can be used, and the selected flow will be used to enter the code.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果設定此欄位，可以使用 OAuth 裝置認證碼設定檔，並使用所選的流程來輸入認證碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7f4e4054fbe132e1">
<source>Other global settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>其他全域設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbadde673052efc02">
<source>Web Certificate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>網頁伺服器憑證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s84c5a011acd608c9">
<source>Event retention</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>事件紀錄保存時長</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2536ac8d32d2e63f">
<source>Duration after which events will be deleted from the database.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>事件紀錄在被從資料庫刪除前的時長。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7b1fba26d245cb1c">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source>When using an external logging solution for archiving, this can be set to "minutes=5".</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果使用外部日誌紀錄解決方案時，可以設定為「minutes=5」。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s44536d20bb5c8257">
<source>This setting only affects new Events, as the expiration is saved per-event.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>此設定僅會影響新的事件紀錄，舊的紀錄到期時間已經設定。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3bb51cabb02b997e">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source>Format: "weeks=3;days=2;hours=3,seconds=2".</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>格式：（weeks=3;days=2;hours=3,seconds=2）。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s04bfd02201db5ab8">
<source>Set custom attributes using YAML or JSON. Any attributes set here will be inherited by users, if the request is handled by this tenant.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用 YAML 或 JSON 設定客製化特徵項。如果是此租戶處理的要求，這裡設定的任何特徵項都將被使用者繼承。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7f9e79189a3d19e2">
<source>Tenants</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>租戶</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s164be9a7537b99f6">
<source>Configure visual settings and defaults for different domains.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>為不同的網域設定視覺化設定和各項預設值。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4802636d55022ed3">
<source>Default?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>是否為預設</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s69a56a3022c4be7f">
<source>Tenant(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>租戶</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1b606acd76ba2c4c">
<source>Update Tenant</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新租戶</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s773aa6621d7e37b7">
<source>Create Tenant</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立租戶</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8cb7bb82e96d5d77">
<source>Policies</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sec1808532fe107b9">
<source>Allow users to use Applications based on properties, enforce Password Criteria and selectively apply Stages.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>允許使用者根據屬性使用應用程式、執行密碼的標準，和有選擇性地應用在階段。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se16ac750b81fa93d">
<source>Assigned to <x id="0" equiv-text="${item.boundTo}"/> object(s).</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已分配给 <x id="0" equiv-text="${item.boundTo}"/> 個物件。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5a48d5171e1a1522">
<source>Warning: Policy is not assigned.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：政策未被分配。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s544142ce35050751">
<source>Test Policy</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>測試政策</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s00c8354318addfa0">
<source>Policy / Policies</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>政策</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s76da2c978dcc5ef4">
<source>Successfully cleared policy cache</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功清除政策快取</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa717841a602fe7d8">
<source>Failed to delete policy cache</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未能清除政策快取</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3ed5607ad78d4224">
<source>Clear cache</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>清除快取</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1b07757762cda372">
<source>Clear Policy cache</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>清除政策快取</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s15b46b78edebb20a">
<source>Are you sure you want to clear the policy cache? This will cause all policies to be re-evaluated on their next usage.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您確定要清除政策快取嗎?這將會導致所有政策在下次使用時重新評價。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s62ddcbaaa91d120d">
<source>Reputation scores</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>名譽分數</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd080b2370aa82967">
<source>Reputation for IP and user identifiers. Scores are decreased for each failed login and increased for each successful login.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>IP 和使用者識別碼的名譽。每次登入失敗都會降低分數，反之每次成功登入都會增加分數。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s09242207b5b8f83c">
<source>IP</source>
<target>IP</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7d684b6257284e55">
<source>Score</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分數</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s10d2dbc4613397f0">
<source>Updated</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最後更新時間</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa33d061d2ade20aa">
<source>Reputation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>名譽</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9f26843287bb592d">
<source>Groups</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4dcb9288f7e9e4d7">
<source>Group users together and give them permissions based on the membership.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將使用者分組，並依照成員資格給予權限。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s62f93cfcb45d5a06">
<source>Superuser privileges?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>是否擁有超級使用者權限</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9fdda7ea4642306c">
<source>Group(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s416a540b16275f2e">
<source>Create Group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7c5774fad9d050ce">
<source>Create group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2a12e0b5527ff99a">
<source>Enabling this toggle will create a group named after the user, with the user as member.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用此選項時，將會建立以使用者名稱為名的群組，而使用者將會成為其成員。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6b6e6eb037aef7da">
<source>Use the username and password below to authenticate. The password can be retrieved later on the Tokens page.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用以下使用者名稱和密碼進行認證，密碼可以從權杖頁面中取得。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf6e1665c7022a1f8">
<source>Password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbb57cd8a3ed12915">
<source>Valid for 360 days, after which the password will automatically rotate. You can copy the password from the Token List.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>有效期限為360天，之後密碼將會自動輪替。您可以在權杖列表中複製密碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4414164d120de61a">
<source>The following objects use <x id="0" equiv-text="${objName}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用以下物件 <x id="0" equiv-text="${objName}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s92e241c9f3c101a2">
<source>connecting object will be deleted</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>連線的物件將被刪除</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se6a13beff646557b">
<source>Successfully updated <x id="0" equiv-text="${this.objectLabel} ${this.obj?.name}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新 <x id="0" equiv-text="${this.objectLabel} ${this.obj?.name}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s14401ff4a0cba208">
<source>Failed to update <x id="0" equiv-text="${this.objectLabel}"/>: <x id="1" equiv-text="${e.toString()}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無法更新 <x id="0" equiv-text="${this.objectLabel}"/>: <x id="1" equiv-text="${e.toString()}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa95a538bfbb86111">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source>Are you sure you want to update <x id="0" equiv-text="${this.objectLabel}"/> "<x id="1" equiv-text="${this.obj?.name}"/>"?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您確定要更新 <x id="0" equiv-text="${this.objectLabel}"/> 「<x id="1" equiv-text="${this.obj?.name}"/>」嗎？</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc92d7cfb6ee1fec6">
<source>Successfully updated password.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新密碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se5498954255620b4">
<source>Successfully sent email.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功發送電子郵件。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s44ea4e9a81ce730d">
<source>Email stage</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>電子郵件階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdb53ccdd6174e6e3">
<source>Successfully added user(s).</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功加入使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s306a35df5d0d38bb">
<source>Users to add</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>欲加入的使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7d499be3b781a3ca">
<source>User(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7220fcf4fec4e0df">
<source>Remove Users(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>移除使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
<trans-unit id="sea4f08110bb8f15d">
<source>Remove</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>移除</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf466142da6a65052">
<source>Impersonate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>模擬使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s58888ef1ee9b5bb8">
<source>User status</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者狀態</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf9e61f4f8e90f0f1">
<source>Change status</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更改狀態</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf56998949bdf6b33">
<source>Deactivate</source>
<target>停用</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3794c596ee7964ad">
<source>Update password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sce8d867ca5f35304">
<source>Set password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0ae3395d8f48e624">
<source>Successfully generated recovery link</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功產生救援連結</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8ca0dbaec5d48563">
<source>No recovery flow is configured.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未設定救援流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb69119c9f0547bed">
<source>Copy recovery link</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>複製救援連結</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7fa236d26b798301">
<source>Send link</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>傳送連結</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa9dbe2fb284e26fe">
<source>Send recovery link to user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>向使用者傳送救援連結</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s03fd2c252ad7972a">
<source>Email recovery link</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>電子郵件救援連結</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd7fa99e4d82b374a">
<source>Recovery link cannot be emailed, user has no email address saved.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無法使用電子郵件傳送救援連結，因為使用者並沒有設定電子郵件。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s63d89a6ae0969c30">
<source>To let a user directly reset a their password, configure a recovery flow on the currently active tenant.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>若要讓使用者直接重設密碼，請在目前的活動租戶上設定救援流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s720594461542943f">
<source>Add User</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>加入使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4c41f3f4c23e8eaa">
<source>Warning: This group is configured with superuser access. Added users will have superuser access.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：這個群組具有超級使用者權限，加入到此群組的使用者將會取得該權限。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scee721983b1c28d0">
<source>Add existing user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>加入現存使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd600334ec2c39b74">
<source>Create user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s53ad3455d9523b54">
<source>Create User</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s06c163334767a381">
<source>Create Service account</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立服務帳戶</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc744f3691efe310d">
<source>Hide service-accounts</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>隱藏服務帳戶</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="secdb4b4c4e66aa38">
<source>Group Info</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>群組資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s005053d82b712e0a">
<source>Notes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>備註</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s634448e4942cf452">
<source>Edit the notes attribute of this group to add notes here.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>編輯這個群組的備註特徵項來加入備註。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s586d6bd2eca2da93">
<source>Users</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sca7cfe2bef51b2a5">
<source>Root</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Root</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3616cc78631f5893">
<source>Warning: You're about to delete the user you're logged in as (<x id="0" equiv-text="${shouldShowWarning.username}"/>). Proceed at your own risk.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：您即將刪除您正在登入的使用者「<x id="0" equiv-text="${shouldShowWarning.username}"/>」。若選擇繼續請自行承擔風險。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s510c7add9e24c306">
<source>Hide deactivated user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>隱藏停用的使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s94055b4eb957dc8f">
<source>User folders</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者資料夾</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa982875b258fea07">
<source>Successfully added user to group(s).</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功加入使用者到群組。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1bd5920d8adf2bd5">
<source>Groups to add</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>欲加入的群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5f71fa3c53828e30">
<source>Remove from Group(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>從群組中移除</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb4c9ed2a487b238f">
<source>Are you sure you want to remove user <x id="0" equiv-text="${this.targetUser?.username}"/> from the following groups?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您確定要從群組中移除使用者 <x id="0" equiv-text="${this.targetUser?.username}"/> 嗎？</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s964f6725aeb7662f">
<source>Add Group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>加入群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s65ca2f256ea09c11">
<source>Add to existing group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>加入到現存的群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s505fbbdcbc6aa921">
<source>Add new group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立群組並加入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s506beb486fa41241">
<source>Application authorizations</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式授權</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7301a7069b7bc83e">
<source>Revoked?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>是否已撤銷</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd924045605feea63">
<source>Expires</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>有效期限</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1c8916418c334935">
<source>ID Token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>ID 權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s90760e5e02e95dfe">
<source>Refresh Tokens(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>重新整理權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1b88fa3df4423292">
<source>Last IP</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最後登入的 IP</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se63f9d833700af49">
<source>Session(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>會談</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf679b7a62808287e">
<source>Expiry</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>過期</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sde1907073fd96017">
<source>(Current session)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>(正在使用的會談)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se8dca0132c66ae03">
<source>Permissions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權限</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s76881c01b6a3a8c7">
<source>Consent(s)</source>
<target>同意</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sea2f00b34b385a43">
<source>Successfully updated device.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新裝置。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s858e7ac4b3cf955f">
<source>Static tokens</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>靜態權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfcfcf85a57eea78a">
<source>TOTP Device</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>TOTP 裝置</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6a406aecb2c0e5c5">
<source>Enroll</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>註冊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa0b01f479f40c52d">
<source>Device(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>裝置</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sabb56f74492e7e96">
<source>Update Device</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新裝置</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf05c700a1250824e">
<source>Confirmed</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>裝置驗證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s64a33dcdaf90af26">
<source>User Info</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc44bae5cde0083fa">
<source>Actions over the last week (per 8 hours)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>一周的動作狀態(每 8 小時)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb57dbcda1929c642">
<source>Edit the notes attribute of this user to add notes here.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>編輯這個使用者的備註特徵項來加入備註。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5c18cae48b93138c">
<source>Sessions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>會談</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s27586544c447d9e3">
<source>User events</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者事件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4d31797d81e9cea3">
<source>Explicit Consent</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>明示同意</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb6770fa90be6d8b3">
<source>OAuth Refresh Tokens</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OAuth 重新整理權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s28b3de1561da72b3">
<source>MFA Authenticators</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>多重要素認證器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7a322c89298dd27c">
<source>Successfully updated invitation.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新邀請函。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc554339ffc7b04e7">
<source>Successfully created invitation.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立邀請函。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfcebd18506f1e535">
<source>Flow</source>
<target>流程</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa84a7fd11ba85e88">
<source>When selected, the invite will only be usable with the flow. By default the invite is accepted on all flows with invitation stages.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當選擇時，邀請只能與該流程一起使用。預設情況下，邀請在所有包含邀請階段的流程中都被接受。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7520286c8419a266">
<source>Optional data which is loaded into the flow's 'prompt_data' context variable. YAML or JSON.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可選：載入到流程的「prompt_data」上下文變數。YAML 或 JSON 格式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb8795b799c70776a">
<source>Single use</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>單次使用</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf232d42142eacc23">
<source>When enabled, the invitation will be deleted after usage.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當啟用時，邀請函將在使用後被刪除。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa4a8086275475714">
<source>Select an enrollment flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇註冊流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s839cb09cb2193da9">
<source>Link to use the invitation.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用邀請函的連結。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8226f48cb1a80997">
<source>Invitations</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>邀請函</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s57448f10eb973100">
<source>Create Invitation Links to enroll Users, and optionally force specific attributes of their account.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立邀請函連結來註冊使用者，可選擇強制設定其帳戶的特定特徵項。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4aee34a672e5cfc0">
<source>Created by</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd5ba2d61ee4796fe">
<source>Invitation(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>邀請函</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s96dcf7ec8342c335">
<source>Invitation not limited to any flow, and can be used with any enrollment flow.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>邀請函並未限制用於任何流程，且可以用於任何註冊流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1b42b49e7b392013">
<source>Update Invitation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新邀請函</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s38c72e1cf120b8d8">
<source>Create Invitation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立邀請函</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s802826db4e2c852e">
<source>Warning: No invitation stage is bound to any flow. Invitations will not work as expected.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：邀請流程沒有附加到任何流程。邀請將無法依照預期工作。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2f995efbb1e46b18">
<source>Auto-detect (based on your browser)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>自動偵測（基於您的瀏覽器）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s296fbffaaa7c910a">
<source>Required.</source>
<target>必需。</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s81ecf2d4386b8e84">
<source>Continue</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>繼續</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8b2b2a43fcf688a3">
<source>Successfully updated prompt.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新提示。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5572ac4d2208f5ec">
<source>Successfully created prompt.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立提示。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s54e7a23a95d99649">
<source>Text: Simple Text input</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>文字：簡單文字輸入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s63e54b86e2a2cc43">
<source>Text Area: Multiline text input</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>文字區塊：多行文字輸入。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s12de1c06a1e18cc5">
<source>Text (read-only): Simple Text input, but cannot be edited.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>文字（唯讀）：簡單文字輸入，但無法編輯。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4e5646b23e41231f">
<source>Text Area (read-only): Multiline text input, but cannot be edited.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>文字區塊（唯讀）：多行文字輸入。但無法編輯。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1e4c3de6e12cd87b">
<source>Username: Same as Text input, but checks for and prevents duplicate usernames.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者名稱：與文字輸入相同，但檢查是否與現存有重複。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5462c7f56ed65e6c">
<source>Email: Text field with Email type.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>電子郵件：具有電子郵件類型的文字欄位。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1c5574968b29ab1c">
<source>Password: Masked input, multiple inputs of this type on the same prompt need to be identical.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>密碼：遮罩輸入，同一提示上的多個此類輸入需要相同。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbbb97b1c63507dc0">
<source>Number</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>編號</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdae649fae731e838">
<source>Checkbox</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>核取方塊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s34edeb18f887161d">
<source>Radio Button Group (fixed choice)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選項按鈕群組（固定選項）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s57730b6870e8916c">
<source>Dropdown (fixed choice)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>下拉式選單（固定選項）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sac8252732f2edb19">
<source>Date</source>
<target>日期</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s45960273852a61b2">
<source>Date Time</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>日期時間</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd1f81284eeb7b503">
<source>File</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檔案</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s21e3c227cc2c5873">
<source>Separator: Static Separator Line</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分隔符號：靜態分隔線</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s706af57c1af42c6d">
<source>Hidden: Hidden field, can be used to insert data into form.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>隱藏：隱藏欄位，可用於將資料插入表單。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s40e2c72dae905a50">
<source>Static: Static value, displayed as-is.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>靜態：靜態數值，按原狀顯示。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdd4bd4224c4e943d">
<source>authentik: Locale: Displays a list of locales authentik supports.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>authentik：語言：顯示 authentik 支援的語言列表。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saf84e7732a9e1336">
<source>Preview errors</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>預覽錯誤</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb71ace8e9b35c749">
<source>Data preview</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>資料預覽</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4d53f4b7ff33bedd">
<source>Unique name of this field, used for selecting fields in prompt stages.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這個欄位的獨特名稱，用於在提示階段中選擇。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3b58f8d2155ae90c">
<source>Field Key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>欄位鍵值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2b088ba65eb69b7e">
<source>Name of the form field, also used to store the value.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>表單名稱，也用於儲存數值。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s662fcb3761ad9df7">
<source>When used in conjunction with a User Write stage, use attributes.foo to write attributes.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當與使用者寫入階段結合使用時，請使用 attributes.foo 來撰寫特徵項。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5590dbf7e425789d">
<source>Label</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>標籤</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0c135eba6017d94f">
<source>Label shown next to/above the prompt.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>標籤顯示在提示的旁邊或上方。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sae5d87e99fe081e0">
<source>Required</source>
<target>必需</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s37dbfe2133b74d2d">
<source>Interpret placeholder as expression</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將預先填入解釋為表示式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4a953e6234cb4808">
<source>When checked, the placeholder will be evaluated in the same way a property mapping is.
If the evaluation fails, the placeholder itself is returned.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用時，預先填入將以與屬性對應相同的方式進行評估。如果評估失敗，則返回預先填入本身。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf90be97cb08f3d5a">
<source>Placeholder</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>預先填入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf76ead4c4708dd06">
<source>Optionally provide a short hint that describes the expected input value.
When creating a fixed choice field, enable interpreting as expression and return a
list to return multiple choices.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可選：提供一個簡短提示，描述預期的輸入值。當建立一個固定選擇欄位時，
啟用解釋為表示式，並回傳一個列表以提供多個選擇。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saa7ba2057bd524a1">
<source>Interpret initial value as expression</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將初始值解釋為表示式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd60415c7666859f0">
<source>When checked, the initial value will be evaluated in the same way a property mapping is.
If the evaluation fails, the initial value itself is returned.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用時，初始值將以與屬性對應相同的方式進行評估。如果評估失敗，則返回初始值本身。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa9c7044d9fd1f3e6">
<source>Initial value</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>初始值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="seab35681cbf36755">
<source>Optionally pre-fill the input with an initial value.
When creating a fixed choice field, enable interpreting as expression and
return a list to return multiple default choices.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可選：預先填入輸入框以一個初始值。
當建立一個固定選擇欄位時，啟用解釋為表示式，並回傳一個列表以提供多個預設選擇。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s72c1c17a9bdc76ad">
<source>Help text</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>支援文字</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s584d1c38ad20d560">
<source>Any HTML can be used.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可使用任何 HTML。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2be6121210e2a2f8">
<source>Prompts</source>
<target>提示</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s42fc6f4b64eff5d9">
<source>Single Prompts that can be used for Prompt Stages.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可用於提示階段的單一提示。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s42a1ebe17efda727">
<source>Field</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>欄位</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s41b105819b67ee7a">
<source>Stages</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sec7443a45fd141e5">
<source>Prompt(s)</source>
<target>提示</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scc733ba98740038a">
<source>Update Prompt</source>
<target>更新提示</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s61b6f3e6bc59c6dd">
<source>Create Prompt</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立提示</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sff5bb7742c2896c8">
<source>Target</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>目標</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sae5da213b7f896ed">
<source>Stage</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0a61796c1956d32c">
<source>Evaluate when flow is planned</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在計劃流程時進行評估</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf533f13321fee530">
<source>Evaluate policies during the Flow planning process.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在計劃流程執行時評估政策。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6336fa345e96dde9">
<source>Evaluate when stage is run</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在執行階段時進行評估</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sff3b708e23bb96b2">
<source>Evaluate policies before the Stage is present to the user.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在階段呈現給使用者前評估政策。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0dc46deb8f181baf">
<source>Invalid response behavior</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無效的回應行為</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="seb0805249661d15b">
<source>Returns the error message and a similar challenge to the executor</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>回傳錯誤訊息以及類似的挑戰到執行器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd891d8463d0ebace">
<source>Restarts the flow from the beginning</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>從頭開始重新啟動流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6b9a1dd402750a8a">
<source>Restarts the flow from the beginning, while keeping the flow context</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>從頭開始重新啟動流程，但保持流程的上下文</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbc88fb27a4c3b894">
<source>Configure how the flow executor should handle an invalid response to a challenge given by this bound stage.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定流程執行器在遇到附加的階段中，給出挑戰但收到的無效回應時，應該處理的方式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s916b32ac64ea2b05">
<source>Successfully updated stage.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新階段。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s14c8f36e180d6bbc">
<source>Successfully created stage.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立階段。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf22a28f83cc45fcc">
<source>Stage used to configure a duo-based authenticator. This stage should be used for configuration flows.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於設定基於 Duo 身分認證器的階段。此階段應該使用在設定流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5adafce329aaa853">
<source>Authenticator type name</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分認證器類型的名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s23e6a57201fba25e">
<source>Display name of this authenticator, used by users when they enroll an authenticator.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>顯示這個身分認證器，用於當使用者要註冊一個身分認證器時。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s276d751eb7a186cc">
<source>API Hostname</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>API 主機名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5b6b6e2cb884d59f">
<source>Duo Auth API</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Duo 認證 API</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s240ff02ce3a53dee">
<source>Integration key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>整合金鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s56fd9ed596c724fa">
<source>Secret key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>金鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s88870d7e499e848b">
<source>Duo Admin API (optional)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Duo 管理員 API（可選）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7f13f4a2d0370cf6">
<source>When using a Duo MFA, Access or Beyond plan, an Admin API application can be created.
This will allow authentik to import devices automatically.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當使用 Duo MFA、Access 或 Beyond 計劃時，可以建立一個 Admin API 應用程式。這將允許 authentik 自動匯入裝置。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9a34d1520e320465">
<source>Stage-specific settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段特定的設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0dfc6838c9d07677">
<source>Configuration flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定的流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sebf44d2471b608ad">
<source>Flow used by an authenticated user to configure this Stage. If empty, user will not be able to configure this stage.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於已認證的使用者設定此階段的流程，如果為空則使用者無法設定此階段。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3baf512851453712">
<source>Twilio Account SID</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Twilio 帳號 SID</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa738ce390bc24875">
<source>Get this value from https://console.twilio.com</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>從以下網址取得值 https://console.twilio.com</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa7b56a80ab1801f0">
<source>Twilio Auth Token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Twilio 身分認證權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfe99a8caa70232ab">
<source>Authentication Type</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分認證類型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="safd0363143a46a91">
<source>Basic Auth</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基本身分認證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd06b47084fec0ec5">
<source>Bearer Token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>持有人權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb1751a1411d6874f">
<source>External API URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>外部 API 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbdc1176ff9f93da2">
<source>This is the full endpoint to send POST requests to.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這是項其發送 POST 要求的完整終端節點。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s51da4de00984fe51">
<source>API Auth Username</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>API 認證使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s293ab4331c1dd387">
<source>This is the username to be used with basic auth or the token when used with bearer token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這是與基本身分認證一起使用的使用者名稱，或與持有人權杖一起使用時的權杖。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s634d041fd954ab20">
<source>API Auth password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>API 認證密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb635ad3c2e357d3c">
<source>This is the password to be used with basic auth</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這是與基本身分認證一起使用的密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa92398dba8b12d85">
<source>Mapping</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s38162f615710c7b4">
<source>Modify the payload sent to the custom provider.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>修改發送至客製化供應商的酬載。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5e830ae7688d1219">
<source>Stage used to configure an SMS-based TOTP authenticator.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於設定基於簡訊的 TOTP 身分認證器的階段。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0d5d05bf3d122ced">
<source>Twilio</source>
<target>Twilio</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc3c74f5273df459a">
<source>Generic</source>
<target>通用的</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbbb2180b6aed196e">
<source>From number</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>傳送人電話號碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc647dcb91f6958dd">
<source>Number the SMS will be sent from.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>傳送簡訊的電話號碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0ae0072614320ae2">
<source>Hash phone number</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>雜湊電話號碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9ca3310e1999fd5b">
<source>If enabled, only a hash of the phone number will be saved. This can be done for data-protection reasons. Devices created from a stage with this enabled cannot be used with the authenticator validation stage.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用時，將只會儲存手機號碼的雜湊值。如果有資料保護的需求可以使用此項。啟用此選項的階段建立的裝置，將無法使用身份認證器的認證階段。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s128e7f5f34bfa155">
<source>Stage used to configure a static authenticator (i.e. static tokens). This stage should be used for configuration flows.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於設定靜態身分認證器的流程（即靜態權杖）。此階段應用於設定流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sabf67834e35dede5">
<source>Token count</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖計數</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc5a4711395ffb043">
<source>Stage used to configure a TOTP authenticator (i.e. Authy/Google Authenticator).</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於設定 TOTP 身分認證器的階段（即 Authy/Google 身分認證器）。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9d8ad4b85287131f">
<source>Digits</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>位數</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc04e92d753742189">
<source>6 digits, widely compatible</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>6位數字，廣泛相容各類認證器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdc70195469e83e3f">
<source>8 digits, not compatible with apps like Google Authenticator</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>8位數字，不相容於類似 Google Authenticator 等認證器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0e15f678445dfc45">
<source>Stage used to validate any authenticator. This stage should be used during authentication or authorization flows.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於驗證任何身分認證器的階段。此階段應用於身分認證或授權流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s73c13e5a6f5e38a3">
<source>Device classes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>裝置類別</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s97d1b0070f50c07f">
<source>Static Tokens</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>靜態權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb8168ae309c66abc">
<source>TOTP Authenticators</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>TOTP 身分認證器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sde47e4d8b9b21b59">
<source>WebAuthn Authenticators</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>WebAuthn 身分認證器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8da88a8a5750bce1">
<source>Duo Authenticators</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Duo 身分認證器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4d182bae8a578010">
<source>SMS-based Authenticators</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>透過簡訊進行身分認證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd8d9451f86502d1a">
<source>Device classes which can be used to authenticate.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可用於身分認證的類別。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se2e9f5a32c93e5f7">
<source>Last validation threshold</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最後驗證的時間閾值</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s951281efc92b03fc">
<source>If any of the devices user of the types selected above have been used within this duration, this stage will be skipped.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果上述選擇的任何裝置類型在此時長內被使用過，則將跳過此階段。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s681074b6c1f19c08">
<source>Not configured action</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未設定時的動作</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa2c29dc5ed47b26d">
<source>Force the user to configure an authenticator</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>強制使用者設定一個身分認證器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa30c58514a3dc0fb">
<source>Deny the user access</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>拒絕使用者存取</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1e0de9c4f66dc371">
<source>WebAuthn User verification</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>WebAuthn 使用者驗證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdb7b2173869822bc">
<source>User verification must occur.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者驗證必需發生。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7683363cdf78cf31">
<source>User verification is preferred if available, but not required.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者驗證作為可選項目而非必需。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scb43f5faeb6a7ca9">
<source>User verification should not occur.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者驗證不應發生。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scae166352a31032c">
<source>Configuration stages</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6941a67f0038ba4c">
<source>Stages used to configure Authenticator when user doesn't have any compatible devices. After this configuration Stage passes, the user is not prompted again.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於當使用者沒有相容的裝置時，設定身分認證器的階段。通過此階段後，使用者將不會再收到提示。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7e5af9c6ba6f5cc6">
<source>When multiple stages are selected, the user can choose which one they want to enroll.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當選擇多個階段時，使用者可選擇想使用哪一個註冊。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s34b23ebbac9f6ab9">
<source>User verification</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者驗證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9ea472b555374771">
<source>Resident key requirement</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>常駐金鑰要求</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5fbaeb14f42815e5">
<source>Authenticator Attachment</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分認證器外接裝置</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s502d2473587032e1">
<source>No preference is sent</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不傳送建議選項</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s60cc554fde2676cb">
<source>A non-removable authenticator, like TouchID or Windows Hello</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不可移除的身分認證器，例如 TouchID 或 Windows Hello</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdf1d8edef27236f0">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source>A "roaming" authenticator, like a YubiKey</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>外接式的身分認證器，例如 YubiKey</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfffba7b23d8fb40c">
<source>This stage checks the user's current session against the Google reCaptcha (or compatible) service.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這個階段使用 Google reCaptcha （或其他相容的）服務檢查使用者目前的會談。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfd1af96798dd8a5f">
<source>Public Key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>公鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf339673f0f76a8bd">
<source>Public key, acquired from https://www.google.com/recaptcha/intro/v3.html.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>公鑰，取得自以下網址 https://www.google.com/recaptcha/intro/v3.html。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s83d0f62ad1731a03">
<source>Private Key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>私鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s892d2731a6f22e59">
<source>Private key, acquired from https://www.google.com/recaptcha/intro/v3.html.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>私鑰，取得自以下網址 https://www.google.com/recaptcha/intro/v3.html。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scb6620fcd5bff04c">
<source>Advanced settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>進階設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s39e436de1dc4df4f">
<source>JS URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>JS 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s170b705c55ecb2ae">
<source>URL to fetch JavaScript from, defaults to recaptcha. Can be replaced with any compatible alternative.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於擷取 JavaScript 的網址，預設為 reCAPTCHA。可以替換為任何相容的替代方案。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s275021658614ce9e">
<source>API URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>API 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc8a79fddea3ab4a9">
<source>URL used to validate captcha response, defaults to recaptcha. Can be replaced with any compatible alternative.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於驗證認證碼回應的網址，預設為 reCAPTCHA。可以替換為任何相容的替代方案。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1cd617e7bbe278d0">
<source>Prompt for the user's consent. The consent can either be permanent or expire in a defined amount of time.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者同意的提示。同意可以是永久性的，也可以設定過期時間。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s26513c9dd154f041">
<source>Always require consent</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>總是需要取得同意</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8ce8bdc9cc9c8604">
<source>Consent given last indefinitely</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>給予永久性的同意</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb986f15fa9b17805">
<source>Consent expires.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>給予有期限的同意</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6f328f2d8382d998">
<source>Consent expires in</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>同意有效期限</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se0c660020d9cf5b7">
<source>Offset after which consent expires.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>同意有效期限的偏移量</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s22b10ed263b96194">
<source>Dummy stage used for testing. Shows a simple continue button and always passes.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於測試的假階段。顯示一個「繼續」的按鈕且永遠通過。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdb861d9906f18ac2">
<source>Throw error?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>是否顯示錯誤資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s31ebc5431d677f5d">
<source>SMTP Host</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SMTP 主機</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s289fce7e694b98ac">
<source>SMTP Port</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SMTP 連接埠</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se4a9da0295597e73">
<source>SMTP Username</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SMTP 使用者名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s593db2c00d6516a2">
<source>SMTP Password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SMTP 密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0d4268408182491d">
<source>Use TLS</source>
<target>使用 TLS</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s480c6c40a248f7d2">
<source>Use SSL</source>
<target>使用 SSL</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc1feadd25659c94d">
<source>From address</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>寄件人地址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa248e1021d2c27b5">
<source>Verify the user's email address by sending them a one-time-link. Can also be used for recovery to verify the user's authenticity.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通過發送一次性連結驗證使用者的電子郵件地址。也可用於救援過程中驗證使用者的真實性。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s87b7e3bc944c728c">
<source>Activate pending user on success</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功時啟用待處理的使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9e9c8d99f4c26baf">
<source>When a user returns from the email successfully, their account will be activated.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當使用者成功透過電子郵件返回時，重新啟用他們的帳號。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s618d4e53f455c834">
<source>Use global settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用全域設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sae1e1a59d22609c4">
<source>When enabled, global Email connection settings will be used and connection settings below will be ignored.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用時，將使用全域電子郵件連線設定，以下的連線設定將被忽略。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb1fe947f9ad27b9d">
<source>Token expiry</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖有效期限</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1c6ba8d100453392">
<source>Time in minutes the token sent is valid.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>發送權杖的有效期限（分鐘為單位）。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se47baf2fd16b9d2b">
<source>Template</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>範本</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4af8a3ce5a600855">
<source>Let the user identify themselves with their username or Email address.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>讓使用者利用使用者名稱或電子郵件來標示自己。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s592ab7d2bc1b8973">
<source>User fields</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者欄位</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s61e48919db20538a">
<source>UPN</source>
<target>UPN</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4cdae7635e757555">
<source>Fields a user can identify themselves with. If no fields are selected, the user will only be able to use sources.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者可以用來標示自己的欄位。如果沒有選擇任何欄位，使用者將只能使用來源。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3380d7cbcebe50f6">
<source>Password stage</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>密碼階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s08c91cb1a2cd3d97">
<source>When selected, a password field is shown on the same page instead of a separate page. This prevents username enumeration attacks.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當選擇時，密碼欄位將會顯示在同一頁面上，這樣可以防止使用者名稱列舉攻擊。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd97d8d0906e6cc47">
<source>Case insensitive matching</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者名稱配對不分大小寫</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8aaad223e954f9ca">
<source>When enabled, user fields are matched regardless of their casing.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用時，配對使用者名稱時將無視大小寫。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbab723b98dcfe23f">
<source>Show matched user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>顯示符合的使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se50a08ab71bb96ed">
<source>When a valid username/email has been entered, and this option is enabled, the user's username and avatar will be shown. Otherwise, the text that the user entered will be shown.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當啟用了此選項，且輸入了有效的使用者名稱或電子郵件時，將顯示使用者的使用者名稱和個人檔案圖片。否則，將顯示使用者輸入的文字。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0295ce5d6f635d75">
<source>Source settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>來源設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s91e3a47599412f51">
<source>Sources</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>來源</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s17a679298216aca9">
<source>Select sources should be shown for users to authenticate with. This only affects web-based sources, not LDAP.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇當使用者進行認證時應顯示的來源。此選項將只會影響基於網頁的來源，LDAP 不受影響。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa41aee3ae04c9216">
<source>Show sources' labels</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>顯示來源標籤</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s54cd35e6224ba65d">
<source>By default, only icons are shown for sources. Enable this to show their full names.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>預設的情況下，只會顯示來源的圖示，啟用這個選項來顯示全名。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9ee20003cb116abf">
<source>Passwordless flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無密碼認證流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0c8c4d2bb0a9162a">
<source>Optional passwordless flow, which is linked at the bottom of the page. When configured, users can use this flow to authenticate with a WebAuthn authenticator, without entering any details.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可選：無密碼認證的流程，連結顯示在頁面底部。設定時，使用者可以無須輸入任何詳細資訊，透過此流程搭配 WebAuthn 身分認證器來進行認證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s01a3a7f48ee4edaf">
<source>Optional enrollment flow, which is linked at the bottom of the page.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可選：註冊流程，連結顯示在頁面底部。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s82188c9542510212">
<source>Optional recovery flow, which is linked at the bottom of the page.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可選：救援流程，連結顯示在頁面底部。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3e59b8b2debf0209">
<source>This stage can be included in enrollment flows to accept invitations.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>此階段可以包含在註冊流程中以接受邀請。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s79ad406777feab1f">
<source>Continue flow without invitation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定無邀請函的流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s61ccefd661ac2296">
<source>If this flag is set, this Stage will jump to the next Stage when no Invitation is given. By default this Stage will cancel the Flow when no invitation is given.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果啟用此旗標，當沒有邀請函時這個階段將會跳到下個階段。預設的情況下，此階段將會取消流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdc30bddeda2f0225">
<source>Validate the user's password against the selected backend(s).</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>由選擇的後端來驗證使用者密碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb8d4f44a1d5b9a14">
<source>Backends</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>後端</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sba42248f3f27955c">
<source>User database + standard password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者資料庫 + 標準密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3330adb3f0922f7b">
<source>User database + app passwords</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者資料庫 + 應用程式密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc10db51c9bb77d5c">
<source>User database + LDAP password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者資料庫 + LDAP 密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd35ae4be63df1f9f">
<source>Selection of backends to test the password against.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇要用於測試密碼的後端。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s482ae78809a6822b">
<source>Flow used by an authenticated user to configure their password. If empty, user will not be able to configure change their password.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>經過身分認證的使用者用來設定密碼的流程，如果未設定則使用者將無法變更密碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s77994108c886b965">
<source>Failed attempts before cancel</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>取消前可嘗試的次數</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa9020b93c3bd7235">
<source>How many attempts a user has before the flow is canceled. To lock the user out, use a reputation policy and a user_write stage.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在取消流程前使用者嘗試的次數。要鎖定使用者請使用名譽政策和 user_write 階段。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5170f9ef331949c0">
<source>Show arbitrary input fields to the user, for example during enrollment. Data is saved in the flow context under the 'prompt_data' variable.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>向使用者顯示任意輸入欄位，例如在註冊過程中。資料會保存在流程上下文中的「prompt_data」變數中。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s36cb242ac90353bc">
<source>Fields</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>欄位</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2d5f69929bb7221d">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source><x id="0" equiv-text="${prompt.name}"/> ("<x id="1" equiv-text="${prompt.fieldKey}"/>", of type <x id="2" equiv-text="${prompt.type}"/>)</source>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
<target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<x id="0" equiv-text="${prompt.name}"/> (「<x id="1" equiv-text="${prompt.fieldKey}"/>」，類型為 <x id="2" equiv-text="${prompt.type}"/>)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3b7b519444181264">
<source>Validation Policies</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>驗證政策</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s59691290a232c687">
<source>Selected policies are executed when the stage is submitted to validate the data.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當階段提交時，將執行所選政策以驗證資料。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbf4ef82e04772a4e">
<source>Delete the currently pending user. CAUTION, this stage does not ask for confirmation. Use a consent stage to ensure the user is aware of their actions.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>刪除目前待處理的使用者。注意，這個階段不會要求確認。使用同意階段以確保使用者意識到他們的動作。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8cc920e6a8430a0d">
<source>Log the currently pending user in.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將待處理的使用者登入。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb85ffe141d7c229d">
<source>Session duration</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>會談的持續時間</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sece294cd51a85745">
<source>Determines how long a session lasts. Default of 0 seconds means that the sessions lasts until the browser is closed.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>決定會談將持續多久。預設值「seconds=0」表示會談會持續到關閉瀏覽器為止。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf7949fbbab2eb566">
<source>Different browsers handle session cookies differently, and might not remove them even when the browser is closed.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不同的瀏覽器處理會談 cookies 方法各異，在關閉瀏覽器後可能不會移除它。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s53bbc3ae4b5fa1d0">
<source>See here.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更多資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2512334108f06a5a">
<source>Stay signed in offset</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登入的持續時間</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1608b2f94fa0dbd4">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source>If set to a duration above 0, the user will have the option to choose to "stay signed in", which will extend their session by the time specified here.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果持續時間大於零，使用者介面上將會有「保持登入」選項。這將會依照設定的時間延長會談。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s542a71bb8f41e057">
<source>Terminate other sessions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>終止其他會談</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa920231366378c90">
<source>When enabled, all previous sessions of the user will be terminated.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當啟用後，所有之前的會談將會被終止。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfee06600c15082a9">
<source>Remove the user from the current session.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>移除使用者目前的會談。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s927398c400970760">
<source>Write any data from the flow's context's 'prompt_data' to the currently pending user. If no user
is pending, a new user is created, and data is written to them.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將流程上下文中的「prompt_data」的任何資料寫入當前待處理的使用者。如果沒有待處理的使用者，則建立一個新使用者，並將資料寫入該使用者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb379d861cbed0b47">
<source>Never create users</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不建立使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s81d673755a86a4f0">
<source>When no user is present in the flow context, the stage will fail.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當流程上下文中不存在使用者時，階段將會失敗。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9940e3f073fbdbd4">
<source>Create users when required</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>需要時建立使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5414356cc10e80fe">
<source>When no user is present in the the flow context, a new user is created.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當流程上下文中不存在使用者時，建立使用者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s57337099d96ce6d2">
<source>Always create new users</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>總是建立使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se80dd66f23b4fc39">
<source>Create a new user even if a user is in the flow context.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>總是建立使用者，即便流程上下文中存在使用者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sed3512fe4560c7f4">
<source>Create users as inactive</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立停用狀態的使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9193ef1a39a6c872">
<source>Mark newly created users as inactive.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將建立的使用者標記為停用狀態。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s89d1847b5e4ad225">
<source>User path template</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者路徑範本</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s18269e3889d6fa54">
<source>Path new users will be created under. If left blank, the default path will be used.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者將會建立在此路徑下。如果留空則使用預設路徑。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc1cb0eef9ed94e6a">
<source>Newly created users are added to this group, if a group is selected.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果有選擇群組，使用者將會被加入到該群組。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd8417b41ca27bc8f">
<source>New stage</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新增階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s293801033f9fc0d0">
<source>Create a new stage.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立一個階段。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s71633a67e0d7c0e4">
<source>Successfully imported device.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功匯入裝置。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7d61705dfb120d7b">
<source>The user in authentik this device will be assigned to.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>此裝置將被分配給的 authentik 中的使用者。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5eaf1d304e03ed4b">
<source>Duo User ID</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Duo 使用者 ID</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s003847d8bc01c676">
<source>The user ID in Duo, can be found in the URL after clicking on a user.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Duo 的使用者 ID，點選使用者後可以在網址列上找到。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbbc806ea3987c781">
<source>Automatic import</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>自動匯入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s77299a9d3dd932cd">
<source>Successfully imported <x id="0" equiv-text="${res.count}"/> devices.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功匯入 <x id="0" equiv-text="${res.count}"/> 個裝置。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6a615f6165ef01c9">
<source>Start automatic import</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>開始自動匯入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9f83d7768aea548a">
<source>Or manually import</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>或使用手動匯入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sddc8efe94cb8c210">
<source>Stages are single steps of a Flow that a user is guided through. A stage can only be executed from within a flow.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段是流程中使用者被引導通過的單一步驟。階段只能在流程內部執行。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb69a4b0acd0895f2">
<source>Flows</source>
<target>流程</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0eaf755fa88c8d97">
<source>Stage(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3914cb410fca44d4">
<source>Import</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>匯入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8a67b33a0d70d322">
<source>Import Duo device</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>匯入 Duo 裝置</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s48cf8fd56b1237ed">
<source>Successfully updated flow.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc3e0c240b159fbce">
<source>Successfully created flow.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s925936f647ae52cc">
<source>Shown as the Title in Flow pages.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>作為標題顯示在流程頁面。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s50719dda8f90abf4">
<source>Visible in the URL.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>顯示於網址列中。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0f4c6540c30bd8b4">
<source>Designation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用目的</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb25d9afe10941425">
<source>Decides what this Flow is used for. For example, the Authentication flow is redirect to when an un-authenticated user visits authentik.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>決定此流程的用途。例如當未經認證的使用者存取 authentik 時，將其重新導向到身分認證流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb36e4c05244278c1">
<source>No requirement</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不需要</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7b105164d209f670">
<source>Require authentication</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>需要身分認證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s239c2a351cde6d39">
<source>Require no authentication.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>需要無身分認證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s98beadfeeb3acb66">
<source>Require superuser.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>需要超級使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfad9279cc42c6b61">
<source>Required authentication level for this flow.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這個流程所需的身分認證等級。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb56674c9ea4f0588">
<source>Behavior settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>行為設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb6d7d58cb0a1544e">
<source>Compatibility mode</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>相容模式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s14ace18ccf4fb86d">
<source>Increases compatibility with password managers and mobile devices.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>提升對密碼管理器和行動裝置的相容性。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scfbc2f1396ee8550">
<source>Denied action</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>拒絕時動作</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sff38031cf061e3ae">
<source>Will follow the ?next parameter if set, otherwise show a message</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果有設定「?next」參數則重新導向，反之則顯示訊息</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s936bf4342b182ad4">
<source>Will either follow the ?next parameter or redirect to the default interface</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果有設定「?next」參數則重新導向，反之則重新導向到預設介面</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s22b0e8c5277dd5a9">
<source>Will notify the user the flow isn't applicable</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將會通知使用者流程無法適用</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2eeca5cfc99ef19b">
<source>Decides the response when a policy denies access to this flow for a user.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>決定當這個流程的使用者被政策拒絕存取時的回應。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbaf20067de176c90">
<source>Appearance settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>外觀設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2e4818861000b13f">
<source>Layout</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>版面設計</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1efbfc3937d565bd">
<source>Background</source>
<target>背景</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s374abf1a54d87b67">
<source>Background shown during execution.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>執行過程中顯示的背景。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3ebf4c166058afce">
<source>Clear background</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>清除背景</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb24755ea94bef31d">
<source>Delete currently set background image.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>刪除目前設定的背景圖片。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb904f23f17b60c3a">
<source>Successfully imported flow.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功匯入流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s344c4a2a48997e18">
<source>.yaml files, which can be found on goauthentik.io and can be exported by authentik.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>.yaml 檔案，可以在 goauthentik.io 中找到且可以從 authentik 中匯出。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc816360d6f5a1eeb">
<source>Flows describe a chain of Stages to authenticate, enroll or recover a user. Stages are chosen based on policies applied to them.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>流程描述了一系列階段，用於認證、註冊或救援使用者。根據應用於它們的政策選擇階段。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6f857299d5db1ecf">
<source>Flow(s)</source>
<target>流程</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9e830cbc0b42a514">
<source>Update Flow</source>
<target>更新流程</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2f1bcfcc5cae94c3">
<source>Create Flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s832282d415294df4">
<source>Import Flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>匯入流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s098237f7ccb4dc4a">
<source>Successfully cleared flow cache</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功清除流程的快取</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s59572c1be31a812e">
<source>Failed to delete flow cache</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無法刪除流程的快取</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa2b727168b090d34">
<source>Clear Flow cache</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>清除流程的快取</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf12d588a76ba7e51">
<source>Are you sure you want to clear the flow cache?
This will cause all flows to be re-evaluated on their next usage.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您確定要清除流程快取嗎？這將導致所有流程在下次使用時重新評估。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbe47a5bdeec19ab0">
<source>Stage binding(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfa88f413e287bb0f">
<source>Stage type</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段類型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s04440099d97c0bef">
<source>Edit Stage</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>編輯階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s980270d0fab7ecb3">
<source>Update Stage binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新階段附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfe938c1585e0bf68">
<source>These bindings control if this stage will be applied to the flow.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這些附加控制此階段是否將應用於流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfac6f995c7670559">
<source>No Stages bound</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>沒有已附加的階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s955c1fec1c6fb970">
<source>No stages are currently bound to this flow.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>目前沒有階段附加到此流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9a393a04eaf1eb0e">
<source>Create Stage binding</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立階段附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s207e8b106806d7e4">
<source>Bind stage</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>附加階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scc2e420c54dc8089">
<source>Bind existing stage</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>附加已存在的階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s30d1f50f476c3f48">
<source>Flow Overview</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>流程概覽</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s77099d752f1ab773">
<source>Related actions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>關聯的動作</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd07866d9f38b2c50">
<source>Execute flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>執行流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9ff3121d30f88d52">
<source>Normal</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>正常執行</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6e4c997a101b6abf">
<source>with current user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用目前使用者執行</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8ecdbff1a7329b64">
<source>with inspector</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>和流程檢閱器一起執行</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3576aead3e68c5c9">
<source>Export flow</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>匯出這個流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s293aa6a6446fb153">
<source>Export</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>匯出</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se2c3cbf2ed1403f1">
<source>Stage Bindings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段附加</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s78c08391ffbfb8c0">
<source>These bindings control which users can access this flow.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這些附加控制哪些使用者可以存取此流程。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc1a1ff47c058bb09">
<source>Event Log</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>事件日誌</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s65d67612999165e9">
<source>Event <x id="0" equiv-text="${this.event.pk}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>事件 <x id="0" equiv-text="${this.event.pk}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s455de2f740b073fd">
<source>Event info</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>事件資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb41b2cfbbc52565b">
<source>Created</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已建立</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s037bc6d25a03c3c8">
<source>Successfully updated transport.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新通道。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1575a15cee001915">
<source>Successfully created transport.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立通道。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4acf840bc792c3ae">
<source>Local (notifications will be created within authentik)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>本機（通知將會透過 authentik 建立）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sede0abbf2b612812">
<source>Webhook (generic)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Webhook (通用)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s76f5dca6404a1210">
<source>Webhook (Slack/Discord)</source>
<target>Webhook（Slack/Discord）</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6873bdbfa24615fb">
<source>Webhook URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Webhook 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s25ec2846f6b88214">
<source>Webhook Mapping</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Webhook 對應</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sca2879d96f58a39c">
<source>Send once</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>僅發送一次</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2430e000b7cfefd0">
<source>Only send notification once, for example when sending a webhook into a chat channel.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>僅發送一次通知，例如在將 webhook 發送到聊天頻道時。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s819509c33a7534ac">
<source>Notification Transports</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通知通道</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s57072ffb92b6c9c8">
<source>Define how notifications are sent to users, like Email or Webhook.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>定義如何向使用者傳送通知，例如電子郵件或 Webhook。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s624256f8a4bb4c89">
<source>Notification transport(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通知通道</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sac1332e6f421526e">
<source>Update Notification Transport</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新通知通道</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6b5002c605b39d6d">
<source>Create Notification Transport</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立通知通道</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0a39e4f61ccafacb">
<source>Successfully updated rule.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新規則。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s72e102414fec81a4">
<source>Successfully created rule.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立規則。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa55ee64c5c51df0f">
<source>Select the group of users which the alerts are sent to. If no group is selected the rule is disabled.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇接收警報的使用者群組。如果沒有選擇群組，則規則將被停用。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sffa171e11d4ae513">
<source>Transports</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通道</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7b18721be331241e">
<source>Select which transports should be used to notify the user. If none are selected, the notification will only be shown in the authentik UI.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇應使用哪些通道來通知使用者。如果沒有選擇任何通道，通知將只會在 authentik 使用者介面中顯示。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scd0cfe87af6f2ff2">
<source>Severity</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>嚴重程度</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s98c3bdf4fd5cdf65">
<source>Notification Rules</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通知規則</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s107bf77afb93c9b8">
<source>Send notifications whenever a specific Event is created and matched by policies.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當特定事件被建立並符合政策時都會發送通知。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf3f9a0feaf083207">
<source>Sent to group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已發送到群組</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc92ed9d5e01d3f24">
<source>Notification rule(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通知規則</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5140d157642d7362">
<source>None (rule disabled)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無（停用規則）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd1146418b344f81f">
<source>Update Notification Rule</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新通知規則</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbbc1de43ab6c1f76">
<source>Create Notification Rule</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立通知規則</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5795b310ab271d20">
<source>These bindings control upon which events this rule triggers.
Bindings to groups/users are checked against the user of the event.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這些附加控制了此規則觸發的事件。附加到群組或使用者的條件會根據事件的使用者來檢查。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s90c3b62194fe8508">
<source>Outpost Deployment Info</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Outpost 部署資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s35f9df7668d5fa79">
<source>View deployment documentation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢視部署文件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sad09c62cb4ebae68">
<source>Click to copy token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>點選這裡複製權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0e03fe2dc5b9164b">
<source>If your authentik Instance is using a self-signed certificate, set this value.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果您的 authentik 執行個體使用自簽憑證，請設定此項。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc21032b0d37882a0">
<source>If your authentik_host setting does not match the URL you want to login with, add this setting.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果您的 authentik_host 設定與您登入的網址不同，請加入此設定。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6f270e1668c036e9">
<source>Successfully updated outpost.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新 Outpost。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s79aed8154d7c472c">
<source>Successfully created outpost.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立 Outpost。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8afc8c5aafb392d3">
<source>Radius</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Radius</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s03970aa76a09982d">
<source>Integration</source>
<target>整合</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9c29565c5ae1cc92">
<source>Selecting an integration enables the management of the outpost by authentik.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇一個整合讓 authentik 對 Outpost 進行管理。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s554ce268e9727e79">
<source>You can only select providers that match the type of the outpost.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您只能選擇與 Outpost 類型相符的供應商。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf9b1c0661a02d9f9">
<source>Configuration</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3abecf1e778c9625">
<source>See more here:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更多資訊請參考：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s74cb3d66f6a668e1">
<source>Documentation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>官方文件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saa8939ac88a76f98">
<source>Last seen</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最後上線時間</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1ac2653a6492b435">
<source><x id="0" equiv-text="${this.outpostHealth.version}"/>, should be <x id="1" equiv-text="${this.outpostHealth.versionShould}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target><x id="0" equiv-text="${this.outpostHealth.version}"/>，應該是<x id="1" equiv-text="${this.outpostHealth.versionShould}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1e176e35c828318c">
<source>Hostname</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>主機名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s322e34cfcba47155">
<source>Not available</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無法使用</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s02b632a9ac24a824">
<source>Last seen: <x id="0" equiv-text="${this.outpostHealth.lastSeen?.toLocaleTimeString()}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最後上線時間： <x id="0" equiv-text="${this.outpostHealth.lastSeen?.toLocaleTimeString()}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa43153d53ae65063">
<source>Unknown type</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未知的類型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5e169e1bac20b4a6">
<source>Outposts</source>
<target>Outposts</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8802553bc57617ee">
<source>Outposts are deployments of authentik components to support different environments and protocols, like reverse proxies.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Outposts 是 authentik 系統中的一部分，負責部署組件以適應各種環境和協議需求，例如作為反向代理。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s84d7d6ebbedcb586">
<source>Health and Version</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>執行狀態和版本</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9bf48a89367282cd">
<source>Warning: authentik Domain is not configured, authentication will not work.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：未設定 authentik 的網域，身分認證將無法使用。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbf5f4c5ba679e847">
<source>Logging in via <x id="0" equiv-text="${item.config.authentik_host}"/>.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>透過以下網址登入。 <x id="0" equiv-text="${item.config.authentik_host}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s59b6028f19d15cda">
<source>No integration active</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>沒有啟用的整合</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9bd59e0ea70a3e4a">
<source>Update Outpost</source>
<target>更新 Outpost</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc8f286ac783c385d">
<source>View Deployment Info</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢視部署資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9ee92717d7f63247">
<source>Detailed health (one instance per column, data is cached so may be out of date)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>健康狀態詳細資訊（每一列一個執行個體，使用快取資料所以可能是過時資訊）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1d49ec5030447643">
<source>Outpost(s)</source>
<target>Outpost(s)</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1a2f8f4b3861583b">
<source>Create Outpost</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立 Outpost</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdc1ef94016f0d855">
<source>Successfully updated integration.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新整合。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc2a1a40a1b4b0170">
<source>Successfully created integration.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立整合。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se9b1fec72ffd8f48">
<source>Local</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>本機端連線</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc1231049879b8d33">
<source>If enabled, use the local connection. Required Docker socket/Kubernetes Integration.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用時，請使用本機連線。需要整合 docker / Kubernetes 的 socket。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s13de04774ff0f210">
<source>Docker URL</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Docker 網址</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa7fcf026bd25f231">
<source>Can be in the format of 'unix://' when connecting to a local docker daemon, using 'ssh://' to connect via SSH, or 'https://:2376' when connecting to a remote system.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當連接到本機 Docker 常駐程式時，將會是「unix: //」的格式，通過 SSH 連線時使用「ssh: //」，或者當連接到遠端系統時，將會是「https://:2376」的格式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saf1d289e3137c2ea">
<source>CA which the endpoint's Certificate is verified against. Can be left empty for no validation.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>驗證終端節點的憑證所需的 CA 憑證。如果為空則不驗證憑證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0f2e070d38cd36df">
<source>TLS Authentication Certificate/SSH Keypair</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>TLS 身分認證憑證或 SSH 金鑰對</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2f58bb9905d2b76f">
<source>Certificate/Key used for authentication. Can be left empty for no authentication.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於身分認證的憑證或金鑰。如果為空則不進行身分認證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8b33660e2ed7212c">
<source>When connecting via SSH, this keypair is used for authentication.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當使用 SSH 連線時，此金鑰對將用於身分認證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa668bd79645c3e06">
<source>Kubeconfig</source>
<target>Kubeconfig</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa85cfb884c17d85d">
<source>Verify Kubernetes API SSL Certificate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>驗證 Kubernetes API 的 SSL 憑證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se78364ee913ae2bd">
<source>New outpost integration</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新增 Outpost 整合</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s68d69ad0271c8ef6">
<source>Create a new outpost integration.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立一個 Outpost 整合。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sae239213b7c70376">
<source>State</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>狀態</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb96629f50f2e7fab">
<source>Unhealthy</source>
<target>不健康</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa8e255492bb6ae0d">
<source>Outpost integration(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Outpost 整合</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9d18948d25c68d66">
<source>Successfully generated certificate-key pair.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功產生金鑰對。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd4ac926e4ebb1cd7">
<source>Common Name</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>主體名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s592425143c4f5834">
<source>Subject-alt name</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>主體別名</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se9d0f12f95b14095">
<source>Optional, comma-separated SubjectAlt Names.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可選：使用逗號分隔多個主體別名。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7609ee54e8a7b05a">
<source>Validity days</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>有效天數</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4c24b2baa377e870">
<source>Successfully updated certificate-key pair.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新金鑰對。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s122f308b5f198ba7">
<source>Successfully created certificate-key pair.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立金鑰對。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s08a8716c214a0efb">
<source>PEM-encoded Certificate data.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>PEM 編碼的憑證資料。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6e612e5a6a359bbb">
<source>Optional Private Key. If this is set, you can use this keypair for encryption.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>可選：私鑰。如果設定此項，您可以使用金鑰對來加密。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s27ac7a47b390e3cb">
<source>Certificate-Key Pairs</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>憑證金鑰對</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb72ebab438cb2983">
<source>Import certificates of external providers or create certificates to sign requests with.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>匯入外部供應商的憑證或建立用於簽署請求的憑證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4b5af7736aedd6c1">
<source>Private key available?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>是否含有私鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1d6e16d86961c782">
<source>Certificate-Key Pair(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>憑證金鑰對</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc1ce2f758935ff48">
<source>Managed by authentik</source>
<target>由 authentik 管理</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf53a78d889b6c775">
<source>Managed by authentik (Discovered)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>由 authentik 管理（已發現）</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sef50d248448e0df1">
<source>Yes (<x id="0" equiv-text="${item.privateKeyType?.toUpperCase()}"/>)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>是 (<x id="0" equiv-text="${item.privateKeyType?.toUpperCase()}"/>)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s09205907b5b56cda">
<source>No</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>否</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s33aa05f435c29753">
<source>Update Certificate-Key Pair</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新憑證金鑰對</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="seffdf887fed7f668">
<source>Certificate Fingerprint (SHA1)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>憑證指紋 (SHA1)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdd6b8b56a811080e">
<source>Certificate Fingerprint (SHA256)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>憑證指紋 (SHA256)</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2a2d3e7c379e9518">
<source>Certificate Subject</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>憑證主題名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s351246c52548086a">
<source>Download Certificate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>下載憑證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s47bd537a3bcebf19">
<source>Download Private key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>下載私鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3a5fec3d73ac9edc">
<source>Create Certificate-Key Pair</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立憑證金鑰對</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s45cb501abd43ba52">
<source>Generate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>產生憑證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf9bddaf910f4eea5">
<source>Generate Certificate-Key Pair</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>產生憑證金鑰對</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="see2bcbc11bb91960">
<source>Successfully updated instance.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新執行個體</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9e51d6de369f320b">
<source>Successfully created instance.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立執行個體</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s92e91071c6a45eb4">
<source>Disabled blueprints are never applied.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>停用的藍圖將永遠不會被應用。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf63c89c0604c288f">
<source>Local path</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>本機路徑</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd6422f7004036cdd">
<source>OCI Registry</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OCI Registry</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se2d65e13768468e0">
<source>Internal</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>內部位置</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scbb7d3154da629f3">
<source>OCI URL, in the format of oci://registry.domain.tld/path/to/manifest.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OCI 網址，格式為「oci://registry.domain.tld/path/to/manifest」。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0195c0df7294228a">
<source>See more about OCI support here:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>關於更多 OCI 支援請參考：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfae395b94a5a0040">
<source>Blueprint</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>藍圖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7e1342d37124b65b">
<source>Configure the blueprint context, used for templating.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定藍圖的上下文，用於作為範本。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6ec8c9d11310300a">
<source>Orphaned</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>孤立</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saab79cd956ee56a9">
<source>Blueprints</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>藍圖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6835db03209b4f94">
<source>Automate and template configuration within authentik.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在 authentik 中自動化和範本化設定。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s23de62f931f7d754">
<source>Last applied</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>最後應用時間</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2708cac1f4942708">
<source>Blueprint(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>藍圖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s880b8b70b22f9977">
<source>Update Blueprint</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新藍圖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sef3d102324bf8561">
<source>Create Blueprint Instance</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立藍圖執行個體</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s32a3efa23718e713">
<source>API Requests</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>API 要求</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sddb3b0176f437721">
<source>Open API Browser</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>打開 API 瀏覽器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5be3c6d61cd9182f">
<source>Notifications</source>
<target>通知</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa3438c7bb4e9cce8">
<source><x id="0" equiv-text="${this.unread}"/> unread</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target><x id="0" equiv-text="${this.unread}"/> 封尚未讀取</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6e6e737601f44b2c">
<source>Successfully cleared notifications</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功清除通知</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8cda828dac449ea5">
<source>Clear all</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>清除全部</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4207178ba0b99418">
<source>A newer version of the frontend is available.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>有可用的新版本前端網頁。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s96b3cddf33e1c853">
web: refactor sidebar capabilities for categorical subsections (#7482) * web: break circular dependency between AKElement & Interface. This commit changes the way the root node of the web application shell is discovered by child components, such that the base class shared by both no longer results in a circular dependency between the two models. I've run this in isolation and have seen no failures of discovery; the identity token exists as soon as the Interface is constructed and is found by every item on the page. * web: fix broken typescript references This built... and then it didn't? Anyway, the current fix is to provide type information the AkInterface for the data that consumers require. * web: rollback dependabot's upgrade of context The most frustrating part of this is that I RAN THIS, dammit, with the updated context and the current Wizard, and it finished the End-to-End tests without complaint. * Due for amendment * Revert "Due for amendment" This reverts commit 829ad5d3f214fa163958593636b28300d010da42. * web: refactor sidebar capabilities for categorical subsections The project "Change Admin UI lists to have sublists per type" requires some initial changes to the UI to facilitate this request. The AdminSidebar is the principle target of this project, and it is embedded in the AdminInterface. To facilitate editing the AdminSidebar as an independent entity, AdminInterface has been moved into its own folder and the AdminSidebar extracted as a standalone Web Component. This removes, oh, about half the code from AdminInterface. A little cleanup with `classMap` was also committed. The rollup config was adjusted to find the new AdminInterface location. The Sidebar uses the global `config: Config` object to check for Enterprise capabilities. Rather than plumb all the way down through the Interface => AdminInterface -> AdminSidebar, I chose to make provide an alternative way of reaching the `config` object, as a *context*. Other configuration objects (Me, UiConfig, Tenant) interfaces will be contextualized as demand warrants. Demand will warrant. Just not yet. <sup>1</sup> The Sidebar has been refactored only slightly; the renderers are entirely the same as they were prior to extraction. What has been changed is the source of information: when we retrieve the current version we story *only* the information, and use type information to ensure that the version we store is the version we care about. The same is true of `impersonation`; we care only about the name of the person being impersonated being present, so we don't store anything else. Fetches have been moved from `firstUpdated` to the constructor. No reason to have the sidebar render twice if the network returns before the render is scheduled. Because the path used to identify the user being impersonated has changed, the `str()` references in the XLIFF files had to be adjusted. **This change is to a variable only and does not require translation.** --- <sup>1</sup> The code is littered with checks to `me()?`, `uiConfig?`, `config?`, etc. In the *context* of being logged in as an administrator those should never be in doubt. I intend to make our interfaces not have any doubt. * Function to help generate sizing solutions across Javascript and CSS. * web: refactor sidebar capabilities for categorical subsections Move open/close logic into the ak-admin-sidebar itself. This commit removes the responsibility for opening/closing the sidebar from the interface parent code and places it inside the sidebar entirely. Since the Django invocation passes none of the properties ak-interface-admin is capable of receiving, this seems like a safe operation. The sidebar now assumes the responsibility for hooking up the window event listeners for open/close and resize. On connection to the DOM, and on resize, the sidebar checks to see if the viewport width meets the criteria for a behavioral change (slide-overlay vs slide-push), and on slide-push automatically opens the sidebar on the assumption that there's plenty of room. In order to support more dynamic styling going forward, I've substituted the 1280px with 80rem, which is the same, but allows for some better styling if someone with older eyes needs to "zoom in" on the whole thing with a larger font size. The hide/show code involves "reaching up" to touch the host's classList. There's a comment indicating that this is a slightly fragile thing to do, but in a well-known way.
2023-11-20 18:24:59 +00:00
<source>You're currently impersonating <x id="0" equiv-text="${this.impersonation}"/>. Click to stop.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您現在正在模擬
<x id="0" equiv-text="${this.impersonation}"/>。點擊停止模擬。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7031e6928c44cedd">
<source>User interface</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者介面</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8849ece8c65e3a18">
<source>Dashboards</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>儀表板</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc265a3e29e1206e4">
<source>Events</source>
<target>事件</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4f1ad6b48a5df506">
<source>Logs</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>日誌</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1823625e6f831d73">
<source>Customisation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>客製化設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc0829ee663ced008">
<source>Directory</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者目錄</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa81e2cdaf6921adc">
<source>System</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>系統</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5515a897ae98bed9">
<source>Certificates</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>憑證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6b79e73ca77148a0">
<source>Outpost Integrations</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Outpost 整合</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sab85321d3b0840b7">
<source>API request failed</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>API 要求失敗</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa3599457b9418bc5">
<source>User's avatar</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者的個人檔案圖片</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9bd9ba84819493d4">
<source>Something went wrong! Please try again later.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>發生錯誤，請稍後再次嘗試。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4090dd0c0e45988b">
<source>Request ID</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>要求 ID</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4d7fe7be1c49896c">
<source>You may close this page now.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您現在可以關閉這個頁面。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf8c76d5fb408de7b">
<source>You're about to be redirect to the following URL.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您即將被重新導向到以下網址。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s197420b40df164f8">
<source>Follow redirect</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>跟隨重新導向</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa11e92683c5860c7">
<source>Request has been denied.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>要求被拒。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8939f574b096054a">
<source>Not you?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不是您？</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc4eedb434536bdb4">
<source>Need an account?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>需要一個帳號嗎？</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s38f774cd7e9b9dad">
<source>Sign up.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>註冊。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa03aa46068460c95">
<source>Forgot username or password?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>忘記使用者名稱或密碼？</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4a87445f3108db7c">
<source>Select one of the sources below to login.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇一下來源進行登入。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s091d5407b5b32e84">
<source>Or</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>或</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se5fd752dbbc3cd28">
<source>Use a security key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用安全金鑰登入</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s670ad066cc0e50a3">
<source>Login to continue to <x id="0" equiv-text="${this.challenge.applicationPre}"/>.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登入以繼續前往 <x id="0" equiv-text="${this.challenge.applicationPre}"/>。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="scf5ce91bfba10a61">
<source>Please enter your password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>請輸入您的密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s85366fac18679f28">
<source>Forgot password?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>忘記密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s14c552fb0a4c0186">
<source>Application requires following permissions:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式需要以下權限：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7073489bb01b3c24">
<source>Application already has access to the following permissions:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式已用擁有已下存取權限：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s98dc556f8bf707dc">
<source>Application requires following new permissions:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應用程式需要新增以下權限：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbd19064fc3f405c1">
<source>Check your Inbox for a verification email.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查您的收件夾確認是否收到驗證電子郵件。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8aff572e64b7936b">
<source>Send Email again.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>再次傳送電子郵件。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdc323c6af4ae9f01">
<source>Successfully copied TOTP Config.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功複製 TOTP 設定。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3687049d1af562c4">
<source>Copy</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>複製</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3643189d1abbb7f4">
<source>Code</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>認證碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfe1c86b42ba13376">
<source>Please enter your TOTP Code</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>請輸入您的 TOTP 認證碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc2ec367e3108fe65">
<source>Duo activation QR code</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Duo 啟用的二維條碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc5668cb23167e9bb">
<source>Alternatively, if your current device has Duo installed, click on this link:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>或者如果您目前裝置已安裝 Duo，請點擊此連結：</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s721d94ae700b5dfd">
<source>Duo activation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Duo 啟用</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s708d9a4a0db0be8f">
<source>Check status</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢查狀態</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s31fba571065f2c87">
<source>Make sure to keep these tokens in a safe place.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>請將這些權杖保存在安全的地方。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc0a0c87d5c556c38">
<source>Phone number</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>電話號碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s04c1210202f48dc9">
<source>Please enter your Phone number.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>請輸入您的電話號碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="seb0c08d9f233bbfe">
<source>Please enter the code you received via SMS</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>請輸入您簡訊收到的認證碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2b7dbba348234a36">
<source>A code has been sent to you via SMS.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>認證碼已透過簡訊傳送。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa84adff85b5e505c">
<source>Open your two-factor authenticator app to view your authentication code.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>開啟您的雙重身份認證器應用程式，檢視您的認證碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7abc9d08b0f70fd6">
<source>Static token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>靜態權杖</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s844fea0bfb10a72a">
<source>Authentication code</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>認證碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3cd84e82e83e35ad">
<source>Please enter your code</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>請輸入您的認證碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s18b910437b73e8e8">
<source>Return to device picker</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>回到選擇裝置頁面</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbcf8604929b6a27a">
<source>Sending Duo push notification</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>傳送到 Duo 推播通知</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3b68883dda2682ed">
<source>Assertions is empty</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>斷言為空</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbbb7318812d64e51">
<source>Error when creating credential: <x id="0" equiv-text="${err}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立憑證時發生錯誤： <x id="0" equiv-text="${err}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sfe199b2564b66054">
<source>Error when validating assertion on server: <x id="0" equiv-text="${err}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在伺服器上驗證斷言發生錯誤： <x id="0" equiv-text="${err}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se409d01b52c4e12f">
<source>Retry authentication</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>重試身分認證</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8d857061510fe794">
<source>Duo push-notifications</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>Duo 推播通知</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s47490298c17b753a">
<source>Receive a push notification on your device.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在您的裝置上接收推播通知。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s16bc281dce5685e8">
<source>Authenticator</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>身分認證器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdefec5401bf67eba">
<source>Use a security key to prove your identity.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用您的安全金鑰證明身分。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd6a025d66f2637d1">
<source>Traditional authenticator</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>傳統身分認證器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb25e689e00c61829">
<source>Use a code-based authenticator.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用基於認證碼的身分認證器。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9e568afec3810bfe">
<source>Recovery keys</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>救援金鑰</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb17e8c70f9a05c77">
<source>In case you can't access any other method.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>萬一您無法存取其他方法。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s97f2dc19fa556a6a">
<source>SMS</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>簡訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0e516232f2ab4e04">
<source>Tokens sent via SMS.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通過簡訊傳送權杖。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6ae0d087036e6d6d">
<source>Select an authentication method.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇一種身分認證方法。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sac17f177f884e238">
<source>Stay signed in?</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>繼續保持登入？</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s859b2e00391da380">
<source>Select Yes to reduce the number of times you're asked to sign in.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇「是」來減少詢問登入的次數。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s420d2cdedcaf8cd0">
<source>Authenticating with Plex...</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用 Plex 進行身分認證中……</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2ddbebcb8a49b005">
<source>Waiting for authentication...</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>等待身分認證中……</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb15fe7b9d09bb419">
<source>If no Plex popup opens, click the button below.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>如果 Plex 彈出視窗未開啟，請點選以下按鈕前往。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbc625b4c669b9ce8">
<source>Open login</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>開啟登入頁面</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd766cdc29b25ff95">
<source>Authenticating with Apple...</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用 Apple 進行身分認證中……</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2c8189544e3ea679">
<source>Retry</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>重試</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc1589121ae2f5f92">
<source>Enter the code shown on your device.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>輸入顯示在您裝置上的認證碼。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s67664f8ee9aea98d">
<source>Please enter your Code</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>請輸入認證碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s455a8fc21077e7f9">
<source>You've successfully authenticated your device.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>您已成功透過裝置認證。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3ab772345f78aee0">
<source>Flow inspector</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>流程檢閱器</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s502884e1977b2c06">
<source>Next stage</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>下一個階段</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb3fa80ccfa97ee54">
<source>Stage name</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段名稱</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbea3c1e4f2fd623d">
<source>Stage kind</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段類型</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2bc8aa1740d3da34">
<source>Stage object</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>階段物件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc3e1c4f1fff8e1ca">
<source>This flow is completed.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>此流程已執行完成。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s342eccabf83c9bde">
<source>Plan history</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>計劃歷史紀錄</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb2f307e79d20bb56">
<source>Current plan context</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>目前計劃的上下文</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sa13e6c8310000e30">
<source>Session ID</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>會談 ID</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6fe64b4625517333">
<source>Powered by authentik</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>由 authentik 技術支援</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sdf34a5599d66f85c">
<source>Background image</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>背景圖片</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7fa4e5e409d43573">
<source>Error creating credential: <x id="0" equiv-text="${err}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立憑證時發生錯誤： <x id="0" equiv-text="${err}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s9d95f09deb601f34">
<source>Server validation of credential failed: <x id="0" equiv-text="${err}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>伺服器驗證憑證失敗： <x id="0" equiv-text="${err}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6c8f05e3be04f62a">
<source>Register device</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>註冊裝置</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3fb39fc45e840f78">
<source>Refer to documentation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>請參考文件</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc741dfb09d3395f0">
<source>No Applications available.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>沒有可用的應用程式。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sf34026321b35315c">
<source>Either no applications are defined, or you don’t have access to any.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>尚未有已定義的應用程式，或是您沒有存取任何應用程式的權限。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1cf2298d92c327a6">
<source>My Applications</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>我的應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s2656433a3b1f7e86">
<source>My applications</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>我的應用程式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s06c92148da82be0d">
<source>Change your password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>變更您的密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sff50532a2d85e32e">
<source>Change password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>變更密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="saf63d34c8601dd41">
<source><x id="0" equiv-text="${prompt.label}"/></source>
<target>
<x id="0" equiv-text="${prompt.label}"/>
</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s33f85f24c0f5f008">
<source>Save</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>儲存</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s045c3b86aae073c1">
<source>Delete account</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>刪除帳號</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4a6aa26413287069">
<source>Successfully updated details</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新個人資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6fcd9b5a87ceccd6">
<source>Open settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>開啟設定</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s8c05cccd470f6b5f">
<source>No settings flow configured.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未設定設定流程</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sb546eb04425e07fa">
<source>Update details</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新個人資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s30205d424e710818">
<source>Successfully disconnected source</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功解除來源的連線</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s67dedada007d4067">
<source>Failed to disconnected source: <x id="0" equiv-text="${exc}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無法解除來自以下來源的連線： <x id="0" equiv-text="${exc}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd2208cd1a767644b">
<source>Disconnect</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>解除連線</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7a4f059aaa029719">
<source>Connect</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>連線</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sababff57115130a0">
<source>Error: unsupported source settings: <x id="0" equiv-text="${source.component}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>錯誤：不支援的來源設定： <x id="0" equiv-text="${source.component}"/></target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sd1031bddc66dc495">
<source>Connect your user account to the services listed below, to allow you to login using the service instead of traditional credentials.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將您的使用者帳號與下方的服務連線，讓您可以直接使用該服務而不使用傳統認證登入。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7968dbed9b106c29">
<source>No services available.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>沒有可用的服務。</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s3a135682bd30bdbb">
<source>Create App password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立應用程式密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s588796ee929a2e4c">
<source>User details</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者個人資訊</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s332a5235948c1a1d">
<source>Consent</source>
<target>同意</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sff945d3f59b93c5e">
<source>MFA Devices</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>多重要素認證裝置</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc54aafeea9c9bab0">
<source>Connected services</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已連接的服務</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sc6b4ebd37b7a91c7">
<source>Tokens and App passwords</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖和應用程式密碼</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sba65ae54d6585c1a">
<source>Unread notifications</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未讀取通知</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s5599c62bb78c631f">
<source>Admin interface</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>管理員介面</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s1298e361e40ee1c5">
<source>Stop impersonation</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>離開模擬模式</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s6abff64e7ff7fde9">
<source>Avatar image</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>個人檔案圖片</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="sbf9c5c5a8e5efad4">
<source>Failed</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>失敗</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="se4cd073c125382af">
<source>Unsynced / N/A</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>未同步或無法使用</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s21b3058faf874368">
<source>Outdated outposts</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>過時的 Outposts</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s51f92b6fa76656ca">
<source>Unhealthy outposts</source>
<target>不健康的 Outposts</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s0fbf6dc6a1966408">
<source>Next</source>
<target>下一步</target>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s4409ada9c5c2a7f8">
<source>Inactive</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>停用</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s7ec7036b249f4f22">
<source>Regular user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>一般使用者</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
<trans-unit id="s27976e94b05c6970">
<source>Activate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用</target>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</trans-unit>
sources/ldap: add support for cert based auth (#5850) * ldap: support cert based auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ldap: default sni switch to off * ldap: `get_info=NONE` on insufficient access error * fix: Make file locale script * ldap: add google ldap attribute mappings * ldap: move google secure ldap blueprint to examples Revert "ldap: add google ldap attribute mappings" This reverts commit 8a861bb92c1bd763b6e7ec0513f73b3039a1adb4. * ldap: remove `validate` for client cert auth not strictly necessary * ldap: write temp cert files more securely * ldap: use first array value for sni when provided csv input * don't specify tempdir we set $TMPDIR in the dockerfile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * limit API to only allow certificate key pairs with private key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use maxsplit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-12 13:41:44 +00:00
<trans-unit id="s1024166475850a65">
<source>Use Server URI for SNI verification</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用伺服器 URI 進行 SNI 驗證</target>
sources/ldap: add support for cert based auth (#5850) * ldap: support cert based auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ldap: default sni switch to off * ldap: `get_info=NONE` on insufficient access error * fix: Make file locale script * ldap: add google ldap attribute mappings * ldap: move google secure ldap blueprint to examples Revert "ldap: add google ldap attribute mappings" This reverts commit 8a861bb92c1bd763b6e7ec0513f73b3039a1adb4. * ldap: remove `validate` for client cert auth not strictly necessary * ldap: write temp cert files more securely * ldap: use first array value for sni when provided csv input * don't specify tempdir we set $TMPDIR in the dockerfile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * limit API to only allow certificate key pairs with private key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use maxsplit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-12 13:41:44 +00:00
</trans-unit>
<trans-unit id="se65beb94fffc3c4b">
<source>Required for servers using TLS 1.3+</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>伺服器需啟用 TLS 1.3版以上</target>
sources/ldap: add support for cert based auth (#5850) * ldap: support cert based auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ldap: default sni switch to off * ldap: `get_info=NONE` on insufficient access error * fix: Make file locale script * ldap: add google ldap attribute mappings * ldap: move google secure ldap blueprint to examples Revert "ldap: add google ldap attribute mappings" This reverts commit 8a861bb92c1bd763b6e7ec0513f73b3039a1adb4. * ldap: remove `validate` for client cert auth not strictly necessary * ldap: write temp cert files more securely * ldap: use first array value for sni when provided csv input * don't specify tempdir we set $TMPDIR in the dockerfile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * limit API to only allow certificate key pairs with private key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use maxsplit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-12 13:41:44 +00:00
</trans-unit>
<trans-unit id="s5506b35a1bceb141">
<source>Client certificate keypair to authenticate against the LDAP Server's Certificate.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於對 LDAP 伺服器的憑證進行認證的用戶端憑證金鑰對。</target>
sources/ldap: add support for cert based auth (#5850) * ldap: support cert based auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ldap: default sni switch to off * ldap: `get_info=NONE` on insufficient access error * fix: Make file locale script * ldap: add google ldap attribute mappings * ldap: move google secure ldap blueprint to examples Revert "ldap: add google ldap attribute mappings" This reverts commit 8a861bb92c1bd763b6e7ec0513f73b3039a1adb4. * ldap: remove `validate` for client cert auth not strictly necessary * ldap: write temp cert files more securely * ldap: use first array value for sni when provided csv input * don't specify tempdir we set $TMPDIR in the dockerfile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * limit API to only allow certificate key pairs with private key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use maxsplit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-12 13:41:44 +00:00
</trans-unit>
<trans-unit id="s4647b2c92638d6fd">
<source>The certificate for the above configured Base DN. As a fallback, the provider uses a self-signed certificate.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>針對上述設定的 Base DN 的憑證。作為備援方案，供應商使用自簽憑證。</target>
sources/ldap: add support for cert based auth (#5850) * ldap: support cert based auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ldap: default sni switch to off * ldap: `get_info=NONE` on insufficient access error * fix: Make file locale script * ldap: add google ldap attribute mappings * ldap: move google secure ldap blueprint to examples Revert "ldap: add google ldap attribute mappings" This reverts commit 8a861bb92c1bd763b6e7ec0513f73b3039a1adb4. * ldap: remove `validate` for client cert auth not strictly necessary * ldap: write temp cert files more securely * ldap: use first array value for sni when provided csv input * don't specify tempdir we set $TMPDIR in the dockerfile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * limit API to only allow certificate key pairs with private key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use maxsplit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-12 13:41:44 +00:00
</trans-unit>
<trans-unit id="scd247ffad6e04ac0">
<source>TLS Server name</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>TLS 伺服器名稱</target>
sources/ldap: add support for cert based auth (#5850) * ldap: support cert based auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ldap: default sni switch to off * ldap: `get_info=NONE` on insufficient access error * fix: Make file locale script * ldap: add google ldap attribute mappings * ldap: move google secure ldap blueprint to examples Revert "ldap: add google ldap attribute mappings" This reverts commit 8a861bb92c1bd763b6e7ec0513f73b3039a1adb4. * ldap: remove `validate` for client cert auth not strictly necessary * ldap: write temp cert files more securely * ldap: use first array value for sni when provided csv input * don't specify tempdir we set $TMPDIR in the dockerfile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * limit API to only allow certificate key pairs with private key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use maxsplit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-12 13:41:44 +00:00
</trans-unit>
<trans-unit id="s2acef4f6ba39bf11">
<source>DNS name for which the above configured certificate should be used. The certificate cannot be detected based on the base DN, as the SSL/TLS negotiation happens before such data is exchanged.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>應使用上述設定憑證的 DNS 名稱。Base DN 無法檢測憑證，因為 SSL/TLS 協商發生在此類資料交換之前。</target>
sources/ldap: add support for cert based auth (#5850) * ldap: support cert based auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ldap: default sni switch to off * ldap: `get_info=NONE` on insufficient access error * fix: Make file locale script * ldap: add google ldap attribute mappings * ldap: move google secure ldap blueprint to examples Revert "ldap: add google ldap attribute mappings" This reverts commit 8a861bb92c1bd763b6e7ec0513f73b3039a1adb4. * ldap: remove `validate` for client cert auth not strictly necessary * ldap: write temp cert files more securely * ldap: use first array value for sni when provided csv input * don't specify tempdir we set $TMPDIR in the dockerfile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * limit API to only allow certificate key pairs with private key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use maxsplit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-12 13:41:44 +00:00
</trans-unit>
<trans-unit id="s000ee3e634868b3c">
<source>TLS Client authentication certificate</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>TLS 用戶端認證憑證</target>
web/admin: theme adjustments (#5944) * web/admin: theme adjustments Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-06-13 13:41:48 +00:00
</trans-unit>
<trans-unit id="s5da52af9b083c29a">
<source>Model</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>模型</target>
web/admin: theme adjustments (#5944) * web/admin: theme adjustments Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-06-13 13:41:48 +00:00
</trans-unit>
<trans-unit id="s3ba9b8aeb686d9f7">
<source>Match events created by selected model. When left empty, all models are matched.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將選擇的模型與建立的事件配對。如果為空則將符合所有模型。</target>
providers/ldap: improve password totp detection (#6006) * providers/ldap: improve password totp detection Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add flag for totp mfa support Signed-off-by: Jens Langhammer <jens@goauthentik.io> * keep support for static tokens Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix migrations Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-06-20 10:09:13 +00:00
</trans-unit>
<trans-unit id="s254d527e3a53dbb7">
<source>Code-based MFA Support</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於認證碼多重要素認證支援</target>
providers/ldap: improve password totp detection (#6006) * providers/ldap: improve password totp detection Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add flag for totp mfa support Signed-off-by: Jens Langhammer <jens@goauthentik.io> * keep support for static tokens Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix migrations Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-06-20 10:09:13 +00:00
</trans-unit>
<trans-unit id="s1889ba2eaeec2f1e">
<source>When enabled, code-based multi-factor authentication can be used by appending a semicolon and the TOTP code to the password. This should only be enabled if all users that will bind to this provider have a TOTP device configured, as otherwise a password may incorrectly be rejected if it contains a semicolon.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當啟用此功能時，可以透過在密碼後加上分號及TOTP認證碼（範例：password:totp認證碼）來使用多重要素驗證。您應只有在所有要連線到此服務的使用者都已設定TOTP裝置的情況下，才啟用此功能。如果使用者的密碼中恰好包含分號，可能會因誤判而被拒絕存取。</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="s9f9492d30a96b9c6">
<source>User type</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者類型</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="s0e427111d750cc02">
<source>Successfully updated license.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新授權許可證</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="s06ae64e621f302eb">
<source>Successfully created license.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立授權許可證</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="s2905c425adae99bd">
<source>Install ID</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>安裝 ID</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="sb18ec434a8a3aafb">
<source>License key</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>授權金鑰</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="s2e109263b73c12d5">
<source>Licenses</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>授權許可證</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="sd49099e9522635f4">
<source>License(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>授權許可證</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="s3be1d90ffa46b7f1">
<source>Enterprise is in preview.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>企業版正處於預覽版本。</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="sd22bd01bdf28c548">
<source>Cumulative license expiry</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>累計授權到期人數</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="sdeb6cee42435dd07">
<source>Update License</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新授權許可證</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="s7df5b92a3f93544f">
<source>Warning: The current user count has exceeded the configured licenses.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>警告：目前的使用者人數已抵達設設定的授權許可上限。</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="s0141f42936495787">
<source>Click here for more info.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>點擊這裡取得更多資訊。</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="s7be2df39f727faa2">
<source>Enterprise</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>企業版</target>
enterprise: initial enterprise (#5721) * initial Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user type Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add external users Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add ui, add more logic, add public JWT validation key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert to not use install_id as session jwt signing key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * switch to PKI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more licensing stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add install ID to form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix bugs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use x5c correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * license checks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use production CA Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * more UI stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to summary Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale, improve ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add direct button Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update link Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove old attributes from ldap Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove is_enterprise_licensed Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix admin interface styling issue Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Update authentik/core/models.py Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Jens L. <jens@beryju.org> * fix default case Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@beryju.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
2023-07-17 15:57:08 +00:00
</trans-unit>
<trans-unit id="s9ce7cc01fb9b5b53">
<source>Manage enterprise licenses</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>管理企業版授權許可證</target>
enterprise: cleanup v2 (#6330) * cleanup minor stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * change default user type to internal to be more consistent Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-21 16:23:51 +00:00
</trans-unit>
<trans-unit id="sf9ebf11ac2645820">
<source>No licenses found.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>找不到授權許可證。</target>
enterprise: cleanup v2 (#6330) * cleanup minor stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * change default user type to internal to be more consistent Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-21 16:23:51 +00:00
</trans-unit>
<trans-unit id="sa1db89262360550b">
<source>Send us feedback!</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>提供建議給我們！</target>
enterprise: cleanup v2 (#6330) * cleanup minor stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * change default user type to internal to be more consistent Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-21 16:23:51 +00:00
</trans-unit>
<trans-unit id="s4015746f55a8d89f">
<source>Get a license</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>取得授權許可證。</target>
enterprise: cleanup v2 (#6330) * cleanup minor stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * change default user type to internal to be more consistent Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-21 16:23:51 +00:00
</trans-unit>
<trans-unit id="sb2cbd06f8e25b47e">
<source>Go to Customer Portal</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>前往客戶入口網站</target>
enterprise: cleanup v2 (#6330) * cleanup minor stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * change default user type to internal to be more consistent Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-21 16:23:51 +00:00
</trans-unit>
<trans-unit id="sf58825457d61c429">
<source>Forecast internal users</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>內部使用者預測</target>
enterprise: cleanup v2 (#6330) * cleanup minor stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * change default user type to internal to be more consistent Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-21 16:23:51 +00:00
</trans-unit>
<trans-unit id="sde9a3f41977ec1f8">
enterprise: licensing fixes (#6601) * enterprise: fix unique index for key, fix field names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * enterprise: update UI to match Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-08-23 11:20:42 +00:00
<source>Estimated user count one year from now based on <x id="0" equiv-text="${this.forecast?.internalUsers}"/> current internal users and <x id="1" equiv-text="${this.forecast?.forecastedInternalUsers}"/> forecasted internal users.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於目前 <x id="0" equiv-text="${this.forecast?.internalUsers}"/> 名內部使用者和預估的 <x id="1" equiv-text="${this.forecast?.forecastedInternalUsers}"/> 名內部使用者來估計一年後的使用者總數。</target>
enterprise: cleanup v2 (#6330) * cleanup minor stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * change default user type to internal to be more consistent Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-21 16:23:51 +00:00
</trans-unit>
<trans-unit id="s4557b6b9da258643">
<source>Forecast external users</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>外部使用者預測</target>
enterprise: cleanup v2 (#6330) * cleanup minor stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * change default user type to internal to be more consistent Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-21 16:23:51 +00:00
</trans-unit>
<trans-unit id="sf52479d6daa0a4a8">
<source>Estimated user count one year from now based on <x id="0" equiv-text="${this.forecast?.externalUsers}"/> current external users and <x id="1" equiv-text="${this.forecast?.forecastedExternalUsers}"/> forecasted external users.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>基於目前 <x id="0" equiv-text="${this.forecast?.externalUsers}"/> 名外部使用者和預估的 <x id="1" equiv-text="${this.forecast?.forecastedExternalUsers}"/> 名外部使用者來估計一年後的使用者總數。</target>
enterprise: cleanup v2 (#6330) * cleanup minor stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * change default user type to internal to be more consistent Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-21 16:23:51 +00:00
</trans-unit>
<trans-unit id="s6196153c4b0c1ea0">
<source>Install</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>安裝</target>
enterprise: cleanup v2 (#6330) * cleanup minor stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * change default user type to internal to be more consistent Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-21 16:23:51 +00:00
</trans-unit>
<trans-unit id="s0285b4bd69130fa3">
<source>Install License</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>安裝授權許可證</target>
web: app icons v2 (#6410) * fix more icons stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * refactor app icon into separate component Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make app icon work correctly in admin list and app view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-28 12:25:56 +00:00
</trans-unit>
<trans-unit id="scef2eb6a2bfe3110">
<source>Internal users might be users such as company employees, which will get access to the full Enterprise feature set.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>內部使用者可能是像公司員工這樣的使用者，他們將取得全部企業版功能的存取權限。</target>
web: app icons v2 (#6410) * fix more icons stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * refactor app icon into separate component Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make app icon work correctly in admin list and app view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-28 12:25:56 +00:00
</trans-unit>
<trans-unit id="sf66389b04fcc219c">
<source>External users might be external consultants or B2C customers. These users don't get access to enterprise features.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>外部使用者可能是像顧問或是 B2C 客戶這樣的使用者，這些使用者不會取得企業版功能的存取權限。</target>
web: app icons v2 (#6410) * fix more icons stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * refactor app icon into separate component Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make app icon work correctly in admin list and app view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-28 12:25:56 +00:00
</trans-unit>
<trans-unit id="s77e8668a27dbc402">
<source>Service accounts should be used for machine-to-machine authentication or other automations.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>服務帳號應用於機器對機器的身份認證或其他自動化操作。</target>
web: app icons v2 (#6410) * fix more icons stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * refactor app icon into separate component Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make app icon work correctly in admin list and app view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-28 12:25:56 +00:00
</trans-unit>
<trans-unit id="s28cbd874ba450b4e">
<source>Less details</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>顯示更少資訊</target>
web: app icons v2 (#6410) * fix more icons stuff Signed-off-by: Jens Langhammer <jens@goauthentik.io> * refactor app icon into separate component Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make app icon work correctly in admin list and app view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-28 12:25:56 +00:00
</trans-unit>
<trans-unit id="s8fa26f65aed77c96">
<source>More details</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>顯示更多資訊</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s08df8d0a773a3ea0">
<source>Remove item</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>移除物件</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s364c4f177a2f8322">
<source>Open API drawer</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>開啟 API 下拉選單</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s9ba989e69344ff29">
<source>Open Notification drawer</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>開啟通知下拉選單</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s14bf17e2a1a2c381">
<source>Restart task</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>重新啟動工作</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s19409e8712ddd369">
<source>Add provider</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新增供應商</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s1f7698c061c208c9">
<source>Open</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>開啟</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="scc3487e74c5a3e89">
<source>Copy token</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>複製權杖</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s424f57afae0caac4">
<source>Add users</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新增使用者</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="sd9f67fbf3f86efcf">
<source>Add group</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>新增群組</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s254a9a23dc1635df">
<source>Import devices</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>匯入裝置</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="sc4fdeccf14be5378">
<source>Execute</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>執行</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s3b3c333481944862">
<source>Show details</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>顯示詳細資訊</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="sb8f855b49234b81b">
<source>Apply</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>套用</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s9d8b8aa2b404c2c8">
<source>Settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定</target>
web: rework and expand tooltips (#6435) * web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-07-31 17:35:09 +00:00
</trans-unit>
<trans-unit id="s7cfe12cd14df9950">
<source>Sign out</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登出</target>
stages/authenticator_static: make static token size adjustable (#6565) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-08-17 21:48:05 +00:00
</trans-unit>
<trans-unit id="s7caa8f7edb920909">
<source>The number of tokens generated whenever this stage is used. Every token generated per stage execution will be attached to a single static device.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>每當使用此階段時產生的權杖數量。每次階段執行產生的每個權杖都將附加到一個固定裝置上。</target>
stages/authenticator_static: make static token size adjustable (#6565) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-08-17 21:48:05 +00:00
</trans-unit>
<trans-unit id="s4aacc4e0277c1042">
<source>Token length</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖長度</target>
stages/authenticator_static: make static token size adjustable (#6565) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-08-17 21:48:05 +00:00
</trans-unit>
<trans-unit id="s6931695c4f563bc4">
<source>The length of the individual generated tokens. Can be increased to improve security.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>每個產生的權杖長度。可以增加以提高安全性。</target>
enterprise: licensing fixes (#6601) * enterprise: fix unique index for key, fix field names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * enterprise: update UI to match Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-08-23 11:20:42 +00:00
</trans-unit>
<trans-unit id="s0dd031b58ed4017c">
<source>Internal: <x id="0" equiv-text="${item.internalUsers}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>內部使用者：<x id="0" equiv-text="${item.internalUsers}"/></target>
enterprise: licensing fixes (#6601) * enterprise: fix unique index for key, fix field names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * enterprise: update UI to match Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-08-23 11:20:42 +00:00
</trans-unit>
<trans-unit id="s57b07e524f8f5c2a">
<source>External: <x id="0" equiv-text="${item.externalUsers}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>外部使用者：<x id="0" equiv-text="${item.externalUsers}"/></target>
website: fix reference to flow stage binding option (#6701) the option name was changed a while back but the docs still used the old name Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-08-30 18:10:36 +00:00
</trans-unit>
<trans-unit id="s7f68101a50f526ee">
<source>Statically deny the flow. To use this stage effectively, disable *Evaluate when flow is planned* on the respective binding.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>靜態拒絕的流程。要有效使用此階段，請在相應的附加上停用「在計劃流程時進行評估」。</target>
web: replace ampersand (#6737) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-02 16:59:17 +00:00
</trans-unit>
<trans-unit id="s911a27022aba349f">
<source>Create and bind Policy</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立政策並附加</target>
web: replace ampersand (#6737) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-02 16:59:17 +00:00
</trans-unit>
<trans-unit id="sb1a4e9b288e2f005">
<source>Federation and Social login</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>聯邦式認證和社群登入</target>
web: replace ampersand (#6737) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-02 16:59:17 +00:00
</trans-unit>
<trans-unit id="s6f367f5604d5056d">
<source>Create and bind Stage</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立階段並附加</target>
web: replace ampersand (#6737) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-02 16:59:17 +00:00
</trans-unit>
<trans-unit id="s1a65ee08832fbfe2">
<source>Flows and Stages</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>流程與階段</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="s4ba4473f3d4ec896">
<source>New version available</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>有可用的新版本</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="s6b1ed7507f26cb4a">
<source>Failure result</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>失敗的結果</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="s2e422519ed38f7d8">
<source>Pass</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>通過</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="s81a45c4fd11e8e1a">
<source>Don't pass</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不要通過</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="s95b73e0f4e47eb9a">
<source>Result used when policy execution fails.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當政策執行失敗所使用的結果</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="s6a3cf855140b9511">
<source>Required: User verification must occur.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>必需：使用者驗證必需發生。</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="sc498a3b05cfe2b08">
<source>Preferred: User verification is preferred if available, but not required.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>推薦：使用者驗證作為可選項目而非必需。</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="s9d2239d2b0402795">
<source>Discouraged: User verification should not occur.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不建議：使用者驗證不應發生。</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="s428b7859907f6db2">
<source>Required: The authenticator MUST create a dedicated credential. If it cannot, the RP is prepared for an error to occur</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>必須：身份認證器必須建立專屬憑證。如果無法建立，依賴方已準備好應對可能發生的錯誤。</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="s33e3766d4a02b042">
<source>Preferred: The authenticator can create and store a dedicated credential, but if it doesn't that's alright too</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>推薦：身份認證器可以建立並儲存專屬憑證，但如果沒有建立也沒關係。</target>
web/admin: fix webauthn label order, add raw value (#6905) * web/admin: fix webauthn label order, add raw value Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert codecov to v3 --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-15 11:12:38 +00:00
</trans-unit>
<trans-unit id="sfb852dd507c25c24">
<source>Discouraged: The authenticator should not create a dedicated credential</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不建議：身份認證器不應建立專屬憑證。</target>
web/flows: improve WebAuthn error messages (#6957) * web/flows: improve WebAuthn error messages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * include localhost Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-25 10:43:24 +00:00
</trans-unit>
<trans-unit id="s028d385389b5aac0">
<source>Lock the user out of this system</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>從這個系統中鎖定使用者</target>
web/flows: improve WebAuthn error messages (#6957) * web/flows: improve WebAuthn error messages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * include localhost Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-25 10:43:24 +00:00
</trans-unit>
<trans-unit id="sd2122c514f0778b5">
<source>Allow the user to log in and use this system</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>允許使用者登入並使用這個系統</target>
web/flows: improve WebAuthn error messages (#6957) * web/flows: improve WebAuthn error messages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * include localhost Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-25 10:43:24 +00:00
</trans-unit>
<trans-unit id="s43fe853bf219a9b8">
<source>Temporarily assume the identity of this user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>臨時扮演該使用者的身份</target>
web/flows: improve WebAuthn error messages (#6957) * web/flows: improve WebAuthn error messages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * include localhost Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-25 10:43:24 +00:00
</trans-unit>
<trans-unit id="se28b5f3fcadaeeb1">
<source>Enter a new password for this user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>為這個使用者輸入新密碼</target>
web/flows: improve WebAuthn error messages (#6957) * web/flows: improve WebAuthn error messages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * include localhost Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-25 10:43:24 +00:00
</trans-unit>
<trans-unit id="s6f5bb31e2733ecd5">
<source>Create a link for this user to reset their password</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>為這個使用者建立連結來重設他們的密碼</target>
web/flows: improve WebAuthn error messages (#6957) * web/flows: improve WebAuthn error messages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * include localhost Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-25 10:43:24 +00:00
</trans-unit>
<trans-unit id="s67ac11d47f1ce794">
<source>WebAuthn requires this page to be accessed via HTTPS.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>WebAuthn 需要使用 HTTPS 存取這個頁面。</target>
web/flows: improve WebAuthn error messages (#6957) * web/flows: improve WebAuthn error messages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * include localhost Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-09-25 10:43:24 +00:00
</trans-unit>
<trans-unit id="se9e9e1d6799b86a5">
<source>WebAuthn not supported by browser.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不支援 WebAuthn 的瀏覽器。</target>
providers/saml: add default RelayState value for IDP-initiated requests (#7100) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-08 22:08:16 +00:00
</trans-unit>
<trans-unit id="sff0ac1ace2d90709">
<source>Use this provider with nginx's auth_request or traefik's forwardAuth. Each application/domain needs its own provider. Additionally, on each domain, /outpost.goauthentik.io must be routed to the outpost (when using a managed outpost, this is done for you).</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將此供應商與 nginx 的 auth_request 或 traefik 的 forwardAuth 一起使用。每個應用程式或網域需要其自己的供應商。此外，在每個網域上，/outpost.goauthentik.io 必須路由到 Outpost（當使用代管的 Outpost 時，這將會自動完成）。</target>
providers/saml: add default RelayState value for IDP-initiated requests (#7100) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-08 22:08:16 +00:00
</trans-unit>
<trans-unit id="scb58b8a60cad8762">
<source>Default relay state</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>預設中繼狀態</target>
providers/saml: add default RelayState value for IDP-initiated requests (#7100) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-08 22:08:16 +00:00
</trans-unit>
<trans-unit id="s6827a456c9dfc6ee">
<source>When using IDP-initiated logins, the relay state will be set to this value.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當使用 Idp 發起的登入時，中繼狀態將會設定為這個值。</target>
web/admin: add additional Flow info (#7155) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-12 12:00:45 +00:00
</trans-unit>
<trans-unit id="s01794c0ee3629c1b">
<source>Flow Info</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>流程資訊</target>
web: fix form default submit handler (#7122) * web/elements: rename renderInlineForm to renderForm set submit handler to empty function Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix all kinds of forms not using the form inheritance correctly Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-12 13:12:46 +00:00
</trans-unit>
<trans-unit id="s24bce955914b1f0a">
<source>Stage used to configure a WebAuthn authenticator (i.e. Yubikey, FaceID/Windows Hello).</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於設定 WebAuthn 身份認證器的階段（例如 Yubikey、FaceID/Windows Hello）。</target>
web: change 'Attributes' to 'Custom attributes' on Invitation Field (#7145) Everywhere else, the label "Attributes" refers to the dictionary field that our core models have and use as a JSON repository for key/value pairs that don't need the full model's awareness or management. Using the same label here, where the term refers to the context data of the invitation itself, may confuse people, so we've changed the label to signal its difference.
2023-10-12 19:33:45 +00:00
</trans-unit>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
<trans-unit id="s1cffe58249b04669">
<source>Internal application name used in URLs.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於網址的應用程式內部名稱。</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="sb3d4f79d9d8b71e5">
<source>Submit</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>提交</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="se2b29e6cfe59414c">
<source>UI Settings</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者介面設定</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="s836148f721d8913b">
<source>Transparent Reverse Proxy</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>透明反向代理</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="s945a6b94361ee45b">
<source>For transparent reverse proxies with required authentication</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於需要身份認證的透明反向代理</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="s40830ec037f34626">
<source>Configure SAML provider manually</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>手動設定 SAML 供應商</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="sea9fc40dfd1d18b1">
<source>Configure RADIUS provider manually</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>手動設定 RADIUS 供應商</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="sa1b0052ae095b9b3">
<source>Configure SCIM provider manually</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>手動設定 SCIM 供應商</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="s15831fa50a116545">
<source>Saving Application...</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>儲存應用程式中……</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="s823abdb61543a826">
<source>Authentik was unable to save this application:</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>authentik 無法儲存這個應用程式：</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="s848288f8c2265aad">
<source>Your application has been saved</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已經儲存您的應用程式</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="s67d858051b34c38b">
<source>Method's display Name.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>方法的顯示名稱。</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="h10ef80d434185070">
<source>Use this provider with nginx's <x id="0" equiv-text="&lt;code&gt;"/>auth_request<x id="1" equiv-text="&lt;/code&gt;"/> or traefik's
<x id="2" equiv-text="&lt;code&gt;"/>forwardAuth<x id="3" equiv-text="&lt;/code&gt;"/>. Each application/domain needs its own provider.
Additionally, on each domain, <x id="4" equiv-text="&lt;code&gt;"/>/outpost.goauthentik.io<x id="5" equiv-text="&lt;/code&gt;"/> must be
routed to the outpost (when using a managed outpost, this is done for you).</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>將此供應商與 nginx 的<x id="0" equiv-text="&lt;code&gt;"/>auth_request<x id="1" equiv-text="&lt;/code&gt;"/>或 traefik 的<x id="2" equiv-text="&lt;code&gt;"/>forwardAuth<x id="3" equiv-text="&lt;/code&gt;"/>一起使用。
每個應用程式或網域需要其自己的供應商。此外，在每個網域上，<x id="4" equiv-text="&lt;code&gt;"/>/outpost.goauthentik.io<x id="5" equiv-text="&lt;/code&gt;"/>必須路由到 Outpost（當使用代管的 Outpost 時，這將會自動完成）。</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
web: change 'Attributes' to 'Custom attributes' on Invitation Field (#7145) Everywhere else, the label "Attributes" refers to the dictionary field that our core models have and use as a JSON repository for key/value pairs that don't need the full model's awareness or management. Using the same label here, where the term refers to the context data of the invitation itself, may confuse people, so we've changed the label to signal its difference.
2023-10-12 19:33:45 +00:00
<trans-unit id="sd18b18f91b804c3f">
<source>Custom attributes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>客製化特徵項</target>
web: change 'Attributes' to 'Custom attributes' on Invitation Field (#7145) Everywhere else, the label "Attributes" refers to the dictionary field that our core models have and use as a JSON repository for key/value pairs that don't need the full model's awareness or management. Using the same label here, where the term refers to the context data of the invitation itself, may confuse people, so we've changed the label to signal its difference.
2023-10-12 19:33:45 +00:00
</trans-unit>
<trans-unit id="s71c5d51d5a357dbd">
<source>Don't show this message again.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>不要再顯示這個通知。</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s3e99ea082ca5ade9">
<source>Failed to fetch</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>擷取失敗</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s98327528f00365a7">
<source>Failed to fetch data.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>擷取資料失敗。</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sf485014051ad0cf7">
<source>Successfully assigned permission.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功分配權限。</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sca7fed2bef53cb99">
<source>Role</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>角色</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sc92c1a54034e21cc">
<source>Assign</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分配</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="scd84d10ee9137070">
<source>Assign permission to role</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分配權限到角色</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s5ee6f1b84e9ebc69">
<source>Assign to new role</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分配給新增角色</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s4afb26a8fae257e9">
<source>Directly assigned</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>直接分配</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sd8051c26e155f043">
<source>Assign permission to user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分配權限給使用者</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sf79f8681e5ffaee2">
<source>Assign to new user</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分配權限給新增使用者</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="saabeb4cab074b0b9">
<source>User Object Permissions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者物件權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s8489d5559dda260c">
<source>Role Object Permissions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>角色物件權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s6b2beba7ab637e9e">
<source>Roles</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>角色</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s96d2bb4be3f5e8aa">
<source>Select roles to grant this groups' users' permissions from the selected roles.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇角色以授予此群組或使用者從所選角色中的權限。</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sb37880a2a7288ef0">
<source>Update Permissions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="se9c07cf256774d81">
<source>Editing is disabled for managed tokens</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>代管權杖的編輯功能已停用</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s78ab26da7f067de8">
<source>Select permissions to grant</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇要取得的權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sdeb90bfd8a80b86b">
<source>Permissions to add</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇要加入的權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s36247910d67421e1">
<source>Select permissions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>選擇權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s67e136af8fc1107b">
<source>Assign permission</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>分配權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sb923723d27df40ba">
<source>Permission(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sc5fb00b25c7f5a02">
<source>Permission</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s1455753daa00f1bc">
<source>User doesn't have view permission so description cannot be retrieved.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者沒有讀取權限，所以無法取得描述。</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sa3a3e09b88ed9791">
<source>Assigned permissions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已分配的權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s9cc631505c17b028">
<source>Assigned global permissions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已分配的全域權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s8f85a0e678846080">
<source>Assigned object permissions</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已分配的物件權限</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s9103a949a3963aa9">
<source>Successfully updated role.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功更新角色</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sdf87c5661b31359e">
<source>Successfully created role.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立角色</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s3484b1e6d0b5335f">
<source>Manage roles which grant permissions to objects within authentik.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>在 authentik 中管理角色來賦予物件權限。</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s259de999919316db">
<source>Role(s)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>角色</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s2ffad156e8332f04">
<source>Update Role</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>更新角色</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="sc5f923729564fbf3">
<source>Create Role</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立角色</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s14bfa8fd1bec8889">
<source>Role doesn't have view permission so description cannot be retrieved.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>角色沒有讀取權限，所以無法取得描述。</target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s7e796fe83982863f">
<source>Role <x id="0" equiv-text="${this._role?.name || &quot;&quot;}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>角色 <x id="0" equiv-text="${this._role?.name || &quot;&quot;}"/></target>
core: Initial RBAC (#6806) * rename consent permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * the user version Signed-off-by: Jens Langhammer <jens@goauthentik.io> t Signed-off-by: Jens Langhammer <jens@goauthentik.io> * initial role Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * some minor table refactoring Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix user, add assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles ui Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix backend Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add assign API for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start adding toggle buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude add_ permission for per-object perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission list for roles Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make sidebar update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix page header not re-rendering? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fixup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add search Signed-off-by: Jens Langhammer <jens@goauthentik.io> * show first category in table groupBy except when its empty Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make model and object PK optional but required together Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow for setting global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude non-authentik permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * exclude models which aren't allowed (base models etc) Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure all models have verbose_name set, exclude some more internal objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * lint fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role perm assign Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unasign for global perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add meta changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clear modal state after submit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add roles to our group Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix duplicate url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make recursive group query more usable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add name field to role itself and move group creation to signal Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start sync Signed-off-by: Jens Langhammer <jens@goauthentik.io> * move rbac stuff to separate django app Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint and such Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix go Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start API changes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make admin interface not require superuser for now, improve error handling Signed-off-by: Jens Langhammer <jens@goauthentik.io> * replace some IsAdminUser where applicable Signed-off-by: Jens Langhammer <jens@goauthentik.io> * migrate flow inspector perms to actual permission Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix license not being a serializermodel Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permission modal to models without view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add additional permissions to assign/unassign permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add action to unassign user permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add permissions tab to remaining view pages Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix flow inspector permission check Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix codecov config? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more API tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ensure viewsets have an order set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * hopefully the last api name change Signed-off-by: Jens Langhammer <jens@goauthentik.io> * make perm modal less confusing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start user view permission page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only make delete bulk form expandable if usedBy is set Signed-off-by: Jens Langhammer <jens@goauthentik.io> * expand permission tables Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add more things Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add user global permission table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests' url names Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tests for assign perms Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add unassign tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rebuild permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent assigning/unassigning permissions to internal service accounts Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only enable default api browser in debug Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role object permissions showing duplicate Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix role link on role object permissions table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix object permission modal having duplicate close buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * return error if user has no global perm and no object perms also improve error display on table Signed-off-by: Jens Langhammer <jens@goauthentik.io> * small optimisation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * optimise even more Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add system permission for non-object permissions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * allow access to admin interface based on perm Signed-off-by: Jens Langhammer <jens@goauthentik.io> * clean Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't exclude base models Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-16 15:31:50 +00:00
</trans-unit>
<trans-unit id="s526e2c66bd51ff5f">
<source>Role Info</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>角色資訊</target>
web: Application wizard v2 with tests (#7004) * A lot of comments about forms. * Adding comments to the wizard. * Broke out the text input into a single renderer. Still works as required. * web: Legibility in the ApplicationForm. This is a pretty good result. By using the LightDOM setting, this provides the existing Authentik form manager with access to the ak-form-horizontal-element components without having to do any cross-border magic. It's not ideal, and it shows up just how badly we've got patternfly splattered everywhere, but the actual results are remarkable. The patterns for text, switch, radio, textarea, file, and even select are smaller and easier here. I'm still noodling on what an unspread search-select element would look like. It's just dependency injection, so it ought to be as straightforward as that. * web: Marking down the start of the 'components' library. * web: Baby steps I become frustrated with my inability to make any progress on this project, so I decided to reach for a tool that I consider highly reliable but also incredibly time-consuming and boring: test driven development. In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler that will send the updated content to some parent object, since what we really want is to orchestrate the state of the user's input with a centralized location. Then, rather than fiddling with the attributes and properties of the various pages, I wanted them to be able to "look up" the values they want, much as we'd expect a standalone form to be able to pull its values from the server, so I added a context object that receives the update event and incorporates the new knowledge about the state of the process into itself. The result is surprisingly satisfying: the first page renders cleanly, displays the content that we want, and as we fiddle with, we can *watch in real time* as the results of the context are updated and retransmitted to all receiving objects. And the sending object gets the results so it re-renders, but it ends up looking the same as it was before the render. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug: the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend their events as standard `input` events, and that actually seems to work well; the browser is decorating it with the right target, with the right `name` attribute, and since we have good definitions of the `value` as a string (the real value of any search object is its UUID4), that works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs), and the latter has flags for "use the first one if it's the only one" and "allow the display of keyless certificates." Not sure why `state()` is blocking the transmission of typing information from the typed element to the context handler, but it's a bug in the typechecker, and it's not a problem so far. * web: tracked down that weirld bug with the radio. Because radio inputs are actually multiples, the events handling for radio is... wonky. If we want our `<ak-radio>` component to be a unitary event dispatcher, saying "This is the element selected," we needed to do more than what was currently being handled. I've intercepted the events that we care about and have placed them into a controller that dictates both the setting and the re-render of the component. This makes it "controlled" (to use the Angular/React/Vue) language and depends on Lit's reactiveElement lifecycle to work, rather than trust the browser, but the browser's experience with respect to the `<input type=radio` is pretty bad: both input elements fire events, one for "losing selection" and one for "gaining selection". That can be very confusing to handle, so we funnel them down in our aggregate radio element to a single event, "selection changed". As a quality-of-life measure, I've also set the label to be unselectable; this means that a click on the label will trigger the selection event, and a long click will not disable selection or confuse the selection event generator. * web: now passing the precommit phase * web: a HACK for Storybook to inject the "use light theme" flag into the body. This isn't really a very good hack; what it does is say that every story is responsible for hacking its theme into the parent. This is very annoying, but it does mean that we can at least show our components in the best light. * web: ak-application-wizard-authentication-by-oauth, and many fixes! 1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify" it. This was causing a bug where retrofitting the eventEmitter to some older components resulted in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted. 2. Removed the "transitional form" from the existing components; they had a two-step where the web component class was just a wrapper around an independent rendering function. While this worked, it was only to make the case that they *were* independent rendering objects and could be supported with the right web component framework. We're halfway there now; the last step will be to transform the horizontal-element and various input CSS into componentized CSS, the way Patternfly-Elements is currently doing. 3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter, don't bother wrapping it in the helper text functionality; just let it be its own thing. This supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability. 4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render function *completely portable*; it's the exact same text that is dropped into... 5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part of me wonders if I could push them both out to a common reference, or a collection of common references. Both components use the PropertyMapping and Sources, and both use the same collection of searches (Crypto, Flow). 6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working. 7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`. This sequence has revealed a bug in the radio control. (It's always the radio control.) If the default doesn't match the current setting, the radio control doesn't behave as expected; it won't change when you fully expect that it should. I'll investigate how to harmonize those tomorrow. * web: Converted our toggle groups to a more streamlined implementation. * web: one more toggle group. * initial api and schema Signed-off-by: Jens Langhammer <jens@goauthentik.io> * separate blueprint importer from yaml parsing Signed-off-by: Jens Langhammer <jens@goauthentik.io> * cleanup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Replace ad-hoc toggle control with ak-toggle-group This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web component that encapsulates all of the needed behavior and exposes a single API with a single event handler, return the value of the option clicked. The results are: Lots of visual clutter is eliminated. A single link of: ``` <div class="pf-c-toggle-group__item"> <button class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy ? "pf-m-selected" : ""}" type="button" @click=${() => { this.mode = ProxyMode.Proxy; }}> <span class="pf-c-toggle-group__text">${msg("Proxy")}</span> </button> </div> <div class="pf-c-divider pf-m-vertical" role="separator"></div> ``` Now looks like: ``` <option value=${ProxyMode.Proxy}>${msg("Proxy")}</option> ``` This also means that the three pages that used the Patternfly Toggle Group could eliminate all of their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also eliminated the `css` import. The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55 lines of code. I still count this a win: we need never write another toggle component again, and any bugs, extensions or features we may want to add can be centralized or forked without risking the whole edifice. * web: minor code formatting issue. * add new "must_created" state to blueprints to prevent overwriting objects Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: adding a storybook for the ak-toggle-group component * Bugs found by CI/CD. * web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs with a web component that encapsulates all of the needed behavior and exposes a single API. The results are: Lots of visual clutter is eliminated. A single search of: ```HTML <ak-search-select .fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => { const args: CryptoCertificatekeypairsListRequest = { ordering: "name", hasKey: true, includeDetails: false, }; if (query !== undefined) { args.search = query; } const certificates = await new CryptoApi( DEFAULT_CONFIG, ).cryptoCertificatekeypairsList(args); return certificates.results; }} .renderElement=${(item: CertificateKeyPair): string => { return item.name; }} .value=${(item: CertificateKeyPair | undefined): string | undefined => { return item?.pk; }} .selected=${(item: CertificateKeyPair): boolean => { return this.instance?.tlsVerification === item.pk; }} ?blankable=${true} > </ak-search-select> ``` Now looks like: ```HTML <ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}> </ak-crypto-certificate-search> ``` There are three searches that do not require there to be a valid key with the certificate; these are supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm) that states that if there is no current certificate in the SAMLProvider and only one certificate can be found in the Authentik database, use that one; this is supported with the boolean property `singleton`. These changes replace 382 lines of object-oriented invocations with 36 lines of declarative configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has been reduced by 46%. Suggestions for a better word than `singleton` are welcome! * web: display tests for CryptoCertificateKeypair search This adds a Storybook for the CryptoCertificateKeypair search, including a mock fetch of the data. In the course of running the tests, we discovered that including the SearchSelect _class_ won't include the customElement declaration unless you include the whole file! Other bugs found: including the CSS from Storybook is different from that of LitElement native, so much so that the adapter needed to be included. FlowSearch had a similar bug. The problem only manifests when building via Webpack (which Storybook uses) and not Rollup, but we should support both in distribution. * Fixed behavioral problem with the radio; the `if` there was preventing the radio from reflecting the default correctly. The observed behavior was that the radio wouldn't "activate" until the item selected during the render pass was clicked on first. * Proxy Provider done. * web: Tactical change. Put all the variants on the second page; it's a longer list, but it's also easier to manage than all those required sub-options. * Rounding out the catalog. * web: SAML Manual Configuration Added a 'design document' that just kinda describes what I'm trying to do, in case I don't get this done by Friday Aug 11, 2023. I had two tables doing the same thing, so I merged them and then wrote a few map/filters to specialize them for those two use cases. Along the way I had to fiddle with the ESLint settings so that underscore-prefixed unused variables would be ignored. I cleaned up the visual appeal of the forms in the LDAP application. I was copy/pasting the "handleProviderEvent" function, so I pulled it out into ApplicationWizardProviderPageBase. Not so much a matter of abstraction as just disliking that kind of duplication; it served no purpose. * Added SAML Story to Storybook. * Web: This is coming together amazingly well. Like, almost too well. * web: 80% of the way there This commit includes the first three pages of the wizard, the completion of the wizard framework with evented handling, and control over progression. Some shortcomings of this design have become evident: it isn't possible to communicate between the steps' wrappers, as they are POJOs without access to the context. An imperative decision-making process has to be inserted in the orchestration layer, which is kinda annoying. But it looks good and it behaves correctly, to the extent that I've given it behavior. It's an excellent foundation. * Linting. * web: application wizard Found where the hook for form validity should go. Excellent! Now I just need to incorporate that basic validation into the business logic and we're good to go. * Turns out that was one layer too many; the topmost component was fine for maintaining the context. * It looks like my brilliant strategy has hit a snag. The idea is simple. Let's start with this picture: ``` <application-wizard .steps=${[... a collection of step objects ...]}> <wizard-main .steps=${(steps from above)}> <application-current-panel> <current-form> ``` - ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be). This context does not know about the steps; it just knows about: the "application" object, the "provider" object, and a discriminator to know *which* provider the user has selected. - ApplicationWizard has Steps that, among other things, provides Panels for: - Application - Pick Provider - Configure Provider - Submit ApplicationProviderPair to the back-end - The WizardFrame renders the CurrentPanel for the CurrentStep The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends messages (events) to ApplicationWizard about the contents of each field as the user is filling out the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later submission. When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next button" on the Wizard is now available. In this way, the user can progress through the system. When they get to the last page, we can provide in the ApplicationWizard with the means to submit the form and/or send the user back to the page with the validation failure. Problem: The context is being updated in real-time, which is triggering re-renders of the form. This leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior. This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of the work. We still want the [Next] button to enable when the form is valid enough to permit that. --- Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized. It *looks* like it should work, it just... doesn't. Not yet. * Late addition: I had an inspiration about how to reduce the way reactivity broke focus by, basically, removing the reactivity and managing the first-time-through lifecycle to prevent the update from causing refocus. It works well! Now I just need to test it. * This application fixes the bug with respect to the wizard-level context being updated incorrectly. Understandings: - To use uncontrolled inputs, which I prefer, the context object should not be a state or property at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The React Way." We're using Web Components, [client-side validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the platform already, and live-validation is problematic for any number of reasons. - The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else until we request a change-of-page. Excellent. - The top level context *must* be a state, but it's better if it's a state never actually used by the top-level context container. The debate about whether or not to make that container a dumb one (`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with the top-level wizard object, but that object does not refer to the state variable being managed in its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the top-level page is to manage the *steps*, not the *content of any step*. A step may change dynamically based on the content of a step, but that's the same thing as *which step*. Lesson: always know what your state is *about*. - Deep merging is a complex subject, but here it's appropriate to our needs. * web: Application Wizard This commit combines a working (but very unpolished) version of the Application Wizard with Jen's code for the CoreTransactionApplicationRequest, resulting in a successful round trip. It fixes a number of bugs with the way ContextProducer decorators were being processed, such that they just weren't working with our current configuration (although they did work fine in Storybook); consumers didn't need to be fixed. It also *removes* the steps-aware context from the Wizard. That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of truth for all of the content. The `WizardContent` part of the application has two parts: The `WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the `WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that populates each panel. YAGNI right now that the panels need to know anything about the steps, and the `WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating. Using props drilling may make more sense here. It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they need to make sense of what they're rendering on-demand, so the function is ``` (panel code) => (context) => (rendered panel) ``` (Yes, that's curried notation. Deal.) * This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but it does log in and navigate to the wizard successfully. * web: completed test for single application, provided new programming language to make it easier to write tests. * Almost there. Missing: The validation is currently not working as expected, and I cannot get the backend to give me meaningful data helping us "go back" to the field that wasn't valid. I really don't want to put all the meaningful validation on the front-end; that's the road to - perdition, the back-end must be usable by people less assiduous than we are. Also: Need to make the button bar work better; maybe each panel can provide a custom button bar if one is needed? * web: Test harness We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this": ``` const deleteProvider = (theSlug) => ([ ["button", '>>>ak-sidebar-item a[href="#/core/providers"]'], ["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`], ["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'], ["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'], ]); ``` It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle. * web: Revised navigation After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow down to the view. It work quite well, and the wizard frame is smaller and smarter for it. I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put them there, and (b) it prevents any confusion about who's in charge of node_modules. * web: Simplify, simplify, simplify Sort-of. This commit changes the way the "wizard step coordinator" layer works, giving the wizard writer much more power over button bar. It still assumes there are only three actions the wizard frame wants to commit: next, back, and close. This empowers the steps themselves to re-arrange their buttons and describe the rules through which transitions occur. * web: resetting the form is not working yet... I vehemently dislike the object-oriented "reset" command; every wizard should start with an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its content from the inside is the correct way to go, but I don't have a good mental image of how to make the ModalButton and the component it invokes interact cleanly, which frustrates the hell out of me. * web: reset As I said, I greatly dislike having to be dependent upon "resets"; I prefer my data to be de novo going into a "new" transaction. That said, we work with what we've got; I've created an event generated by the wizard that says the modal just closed; anything wrapping and implementing the wizard can then capture that event and reset the data. I've also added a pair of functions that create the two states (what step, what form data) anew, so that resetting is as trivial as initializing (and is exactly the same, code-wise). * web: Without error handling, this is complete, but I still need @BeryJu (Jens) for help with the SAML Upload (it doesn't appear to be correctly handled?) and the error handling. * web: revise tests for wizard This commit replaces the previous WDIO instance with a more formal and straightforward process using the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major component has its own test suite, and a test is a sequence of exercises of those components. A test then becomes something as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); expect(await UserLibraryPage.pageHeader).toHaveText("My Applications"); await UserLibraryPage.goToAdmin(); expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, "); await AdminOverviewPage.openApplicationsListPage(); expect(await ApplicationsListPage.pageHeader).toHaveText("Applications"); ApplicationsListPage.startCreateApplicationWizard(); await ApplicationWizard.app.name.setValue(`Test application ${newId}`); await ApplicationWizard.nextButton.click(); await (await ApplicationWizard.getProviderType("ldapprovider")).click(); await ApplicationWizard.nextButton.click(); await ApplicationWizard.ldap.setBindFlow("default-authentication-flow"); await ApplicationWizard.nextButton.click(); await expect(await ApplicationWizard.commitMessage).toHaveText( "Your application has been saved" ); ``` Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for maintaining tests. * web: updating with forms and fixes for eslint complaints. * web/add webdriverIO testing layer This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both locally and remotely, supports strong integration with web components, and is generally robust for use in pipelines. I'll confess to working through a tutorial on how to do this for web components, and this is just chapter 2 (I think there are 5 or so chapters...). There's a makefile, with help! If you just run `make` it tells you: ``` Specify a command. The choices are: help Show this help node_modules Runs `npm install` to prepare this feature precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write test-good-login Test that we can log into the server. Requires a running instance of the server. test-bad-login Test that bad usernames and passwords create appropriate error messages ``` ... because Makefiles are documentation, and documentation belongs in Makefiles. I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major components (a page, a form, a wizard), there's a class that provides human-readable names for human-interactable and human-viewable objects on the page. The LoginPage object, for example, has selectors for the username, password, submit button, and the failure alert; accessing those allows us to test for items as expected., and to write a DSL for "a good login" that's as straightforward as: ``` await LoginPage.open(); await LoginPage.login("ken@goauthentik.io", "eat10bugs"); await expect(UserLibraryPage.pageHeader).toHaveText("My applications"); ``` There was a *lot* of messing around with the LoginPage to get the username and password into the system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because we both keep the buttons inaccessible until the form has something and we "black out" the page (put a darkening filter over it) while accessing the flow, meaning there was a race condition such that the test would attempt to interact with the username or password field before it was accessible. But this works now, which is very nice. ``` JavaScript get inputUsername() { return $('>>>input[name="uidField"]'); } get btnSubmit() { return $('>>>button[type="submit"]'); } async username(username: string) { await this.inputUsername.waitForClickable(); await this.inputUsername.setValue(username); await this.btnSubmit.waitForEnabled(); await this.btnSubmit.click(); } ``` The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my guardrails. * web/adding tests: added comments and cleaned up some administrative features. * web/test: changed the name of one test to reflect it's 'good' status * core/allow alternative postgres credentials This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the `.env` file if they are present, or fallback to the defaults provided if they are not. This is the only place in the Makefile where the database credentials are used directly against postgresql binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those. The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment where this command will be executed," and the shell expresion `${VARIABLE:-default}` means "dereference the environment variable; if it is undefined, used the default value provided." * Re-arrange sequence to avoid recursive make. Nothing wrong with recursive make; it just wasn't essential here. `migrate` is just a build target, not a task. * Cleanup according to the Usage: checkmake [options] <makefile>... checkmake -h | --help checkmake --version checkmake --list-rules Makefile linting tool. * core: added 'help' to the Makefile * get postgres config from authentik config loader Signed-off-by: Jens Langhammer <jens@goauthentik.io> * don't set -x by default Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort help Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update help strings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: test LDAP wizard sequence * web: improve testing by adding test admin user via blueprint * This commit continues the application wizard buildout. In this commit are the following changes: - Added SCIM to the list of available providers - Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer; I'm unhappy with that.) - Fixed the commit messages so that: - icons are set correctly (Success, Danger, Working) - icons are colored correctly according to state - commit message includes a `data-commit-state` field so tests can find it! - Merged the application wizard tests into a single test pass - Isolated common parts of the application wizard tests to reduce unnecessary repetition. All application tests are the same until you reach the provider section anyway. - Fixed the unit tests so they're finding the right error messages and are enabled to display them correctly. - Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder. * web: add radius to application wizard This commit continues the application wizard buildout. In this commit are the following changes: - Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!") - Added Radius to the list of providers we can offer via the wizard - Added `launchUrl` and `UI Settings` to features of the application page the wizard can find - Changed 'SAML Manual Configuration' to just say "SAML Configuration" - Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it easier to target specific forms with unit testing) - Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put back with `--logLevel info` from the command line. * fix blueprints Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update package name Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add dependabot Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prettier run Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic CI Signed-off-by: Jens Langhammer <jens@goauthentik.io> * remove hooks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: application wizard refactor & completion This commit refactors the various components of the Wizard and ApplicationWizard, creating a much more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so far), and for the customer. The Wizard base has been refactored into three components: **AkWizardController** The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant messages contained in the events. It knows of three event categories: - Navigation requests (move to a different step) - Update requests (the current step has updated the business content) - Close requests (close or cancel the wizard). **ak-wizard-frame** The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee` "navigation block"), Buttons, and a DIV into which the main content is rendered. **AkWizard** `AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child class, which will implement the rest. It extends `AKElement`. It provides the basic content needed, such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the frame, and the interface to the `AkWizardController`. **ApplicationWizard** The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from `AkWizard` and provides the business logic for what to do when a form updates, some custom logic for preventing moving through the wizard when the forms are incomplete, and a persistence layer for filling out different providers in the same session. It's simplified a *lot*. The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed via the custom events were more robust, but [strongly typed custom events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er, neck. As it is, the `precommit` pass did very good at preventing the worst disasters. The steps themselves were re-written as objects so that they could take advantage of their `valid` and `disabled` states and provide more meaningful buttons and labels. I think it's a solid compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method. The tests, such as they are, are passing. * Added comment describing new test. * web: ensuring copy from `main` is canon * web: fixes after merge * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: eslint & prettier fixes, plus small aesthetic differences. * Restoring this file. Not sure where it disappears to. * fix label in dark mode Signed-off-by: Jens Langhammer <jens@goauthentik.io> * SCIM Manuel -> SCIM Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix lint errors Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: better converter configuration, CSS repair, and forward-domain-proxy 1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard, but Jens says it is. I've added it. 2. In the process of doing so, I decided that the Provider.converter field was overly complexified; I tried too hard to reduce the number of functions I needed to define, but in the process outsourced some of the logic of converting the Wizard's dataset into a property typed request to the `commit` phase, which was inappropriate. All of the logic about a provider, aside from its display, should be here with the code that distinguishes between providers. This commit makes it so. 3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected CSS which was causing a bit of a weird indent. That has been rectified. * web: running pre-commit after merge. * web: ensure the applications wizard tests finish after current changes * prettier has opinions. * web: application wizard spit & polish The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back and see the message after it's been hidden, so that it will always be available during the test phase. The ApplicationList's old "Create Application Form" button has been restored for the purposes of the test phase. The ApplicationWizard is now available on both the ApplicationList and ProviderList pages. Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the language, to give the user the sense of empowerment. The ShowHintController now has both "hide" and "show" operations, to support the hint restoration. * web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook. * web: I hate getting spanked by prettier. * web: sometimes I wish I had lower standards Anyway, this was a very stupid bug, because by definition function definition arguments don't have uses, they're being defined, not implemented. Fixed, conf fixed to compensate, and consequences conquered. * move context from labs to main Signed-off-by: Jens Langhammer <jens@goauthentik.io> * Revert "move context from labs to main" This reverts commit 3718ee69048966d26b1c357a7d2653fbb3ab613b. * web: reify the data loop I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard for me to read and understand what was happening, and I wrote the darned thing. I decided instead to go with a hard substitution model; each phase of the wizard is responsible for updating the *entire* payload, mostly by creating a new payload and substituting the field value associated with the event. On the receiver, we have to do that *again* to handle the swapping of providers when the user chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev could understand what it's doing, and that's the goal. * Revert "web: reify the data loop" This reverts commit 09fedcacf02a90a021ce9e18c0eb4bec1ef48302. * web: revert the 'lit' to 'lit-labs' for task and context. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-10-18 19:43:37 +00:00
</trans-unit>
<trans-unit id="s2da4aa7a9abeb653">
<source>Pseudolocale (for testing)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>虛擬翻譯語言（用於測試）</target>
core/rbac: fix missing field when removing perm, add delete from object page (#7226) * make object permissions deletable from the object page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix error when removing object permissions form user/role page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * upgrade translation Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-19 12:53:56 +00:00
</trans-unit>
<trans-unit id="s4bd386db7302bb22">
<source>Create With Wizard</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用設定精靈建立</target>
core/rbac: fix missing field when removing perm, add delete from object page (#7226) * make object permissions deletable from the object page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix error when removing object permissions form user/role page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * upgrade translation Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-19 12:53:56 +00:00
</trans-unit>
<trans-unit id="s070fdfb03034ca9b">
<source>One hint, 'New Application Wizard', is currently hidden</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>提示：「新增應用程式設定精靈」目前處於隱藏中</target>
core/rbac: fix missing field when removing perm, add delete from object page (#7226) * make object permissions deletable from the object page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix error when removing object permissions form user/role page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * upgrade translation Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-19 12:53:56 +00:00
</trans-unit>
<trans-unit id="s61bd841e66966325">
<source>External applications that use authentik as an identity provider via protocols like OAuth2 and SAML. All applications are shown here, even ones you cannot access.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用 authentik 作為身份供應商的外部應用程式，透過像 OAuth2 和 SAML 這樣的協議。此處顯示所有應用程式，即使是您無法存取的應用程式也包括在內。</target>
core/rbac: fix missing field when removing perm, add delete from object page (#7226) * make object permissions deletable from the object page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix error when removing object permissions form user/role page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * upgrade translation Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-19 12:53:56 +00:00
</trans-unit>
<trans-unit id="s1cc306d8e28c4464">
<source>Deny message</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>拒絕的訊息</target>
core/rbac: fix missing field when removing perm, add delete from object page (#7226) * make object permissions deletable from the object page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix error when removing object permissions form user/role page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * upgrade translation Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-19 12:53:56 +00:00
</trans-unit>
<trans-unit id="s6985c401e1100122">
<source>Message shown when this stage is run.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>當這個階段執行時會顯示的訊息。</target>
core/rbac: fix missing field when removing perm, add delete from object page (#7226) * make object permissions deletable from the object page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix error when removing object permissions form user/role page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * upgrade translation Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-19 12:53:56 +00:00
</trans-unit>
<trans-unit id="s09f0c100d0ad2fec">
<source>Open Wizard</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>開啟設定精靈</target>
core/rbac: fix missing field when removing perm, add delete from object page (#7226) * make object permissions deletable from the object page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix error when removing object permissions form user/role page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * upgrade translation Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-19 12:53:56 +00:00
</trans-unit>
<trans-unit id="sf2ef885f7d0a101d">
<source>Demo Wizard</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>設定精靈示範</target>
core/rbac: fix missing field when removing perm, add delete from object page (#7226) * make object permissions deletable from the object page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix error when removing object permissions form user/role page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * upgrade translation Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-19 12:53:56 +00:00
</trans-unit>
<trans-unit id="s77505ee5d2e45e53">
<source>Run the demo wizard</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>執行設定精靈示範</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="s4498e890d47a8066">
<source>OAuth2/OIDC (Open Authorization/OpenID Connect)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>OAuth2/OIDC (Open Authorization/OpenID Connect)</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="s4f2e195d09e2868c">
<source>LDAP (Lightweight Directory Access Protocol)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>LDAP (Lightweight Directory Access Protocol)</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="s7f5bb0c9923315ed">
<source>Forward Auth (Single Application)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>轉發認證（單一應用程式）</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="sf8008d2d6b064b95">
<source>Forward Auth (Domain Level)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>轉發認證（網域層級）</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="sfa8a1ffa9fee07d3">
<source>SAML (Security Assertion Markup Language)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SAML (Security Assertion Markup Language)</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="s848a23972e388662">
<source>RADIUS (Remote Authentication Dial-In User Service)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>RADIUS (Remote Authentication Dial-In User Service)</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="s3e902999ddf7b50e">
<source>SCIM (System for Cross-domain Identity Management)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>SCIM (System for Cross-domain Identity Management)</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="sdc5690be4a342985">
<source>The token has been copied to your clipboard</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>權杖已經複製到您的剪貼簿</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="s7f3edfee24690c9f">
<source>The token was displayed because authentik does not have permission to write to the clipboard</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>因為 authentik 無法複製到您的剪貼簿，權杖資訊顯示在畫面上</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="saf6097bfa25205b8">
<source>A copy of this recovery link has been placed in your clipboard</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>救援連結已經複製到您的剪貼簿中</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="s5b8ee296ed258568">
<source>The current tenant must have a recovery flow configured to use a recovery link</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>目前的租戶必需設定救援流程，才能使用救援連結</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="s895514dda9cb9c94">
<source>Create recovery link</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立救援連結</target>
web/admin: small wizard fixes (#7259)
2023-10-23 16:48:12 +00:00
</trans-unit>
<trans-unit id="se5c795faf2c07514">
<source>Create Recovery Link</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>建立救援連結</target>
web/admin: small fixes (#7292) * show user type better on admin interface Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix rendering for backchannel in app form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix missing trailing slash in admin redirect Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-25 16:25:37 +00:00
</trans-unit>
<trans-unit id="s84fcddede27b8e2a">
<source>External</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>外部</target>
web/admin: small fixes (#7292) * show user type better on admin interface Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix rendering for backchannel in app form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix missing trailing slash in admin redirect Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-25 16:25:37 +00:00
</trans-unit>
<trans-unit id="s1a635369edaf4dc3">
<source>Service account</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>服務帳號</target>
web/admin: small fixes (#7292) * show user type better on admin interface Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix rendering for backchannel in app form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix missing trailing slash in admin redirect Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-25 16:25:37 +00:00
</trans-unit>
<trans-unit id="sff930bf2834e2201">
<source>Service account (internal)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>服務帳號（內部）</target>
web/admin: small fixes (#7292) * show user type better on admin interface Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix rendering for backchannel in app form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix missing trailing slash in admin redirect Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-25 16:25:37 +00:00
</trans-unit>
<trans-unit id="s66313b45b69cfc88">
<source>Check the release notes</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>檢視版本資訊</target>
web/admin: small fixes (#7292) * show user type better on admin interface Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix rendering for backchannel in app form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix missing trailing slash in admin redirect Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-25 16:25:37 +00:00
</trans-unit>
<trans-unit id="sb4d7bae2440d9781">
<source>User Statistics</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>使用者統計資料</target>
web/admin: small fixes (#7292) * show user type better on admin interface Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix rendering for backchannel in app form Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix missing trailing slash in admin redirect Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-25 16:25:37 +00:00
</trans-unit>
<trans-unit id="s0924f51b028233a3">
<source>&lt;No name set&gt;</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>&lt;No name set&gt;</target>
web/admin: fix role form reacting to enter (#7330) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-27 09:39:39 +00:00
</trans-unit>
<trans-unit id="sdc9a6ad1af30572c">
<source>For nginx's auth_request or traefik's forwardAuth</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>適用於 nginx 的「auth_request」或 traefik 的「forwardAuth」</target>
web/admin: fix role form reacting to enter (#7330) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-27 09:39:39 +00:00
</trans-unit>
<trans-unit id="sfc31264ef7ff86ef">
<source>For nginx's auth_request or traefik's forwardAuth per root domain</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>適用於每個主網域的 nginx 的「auth_request」或 traefik 的「forwardAuth」</target>
web/admin: fix role form reacting to enter (#7330) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-27 09:39:39 +00:00
</trans-unit>
<trans-unit id="sc615309d10a9228c">
<source>RBAC is in preview.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>RBAC 正處於預覽版本。</target>
web/admin: fix role form reacting to enter (#7330) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-10-27 09:39:39 +00:00
</trans-unit>
<trans-unit id="s32babfed740fd3c1">
<source>User type used for newly created users.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>用於建立使用者的使用者類型。</target>
web/admin: fix chart label on dashboard user page (#7434) * web: fix chart label on dashboard user page * update translation files * fix prettier lint
2023-11-06 12:51:41 +00:00
</trans-unit>
<trans-unit id="s4a34a6be4c68ec87">
<source>Users created</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>已建立使用者。</target>
web/admin: fix chart label on dashboard user page (#7434) * web: fix chart label on dashboard user page * update translation files * fix prettier lint
2023-11-06 12:51:41 +00:00
</trans-unit>
<trans-unit id="s275c956687e2e656">
<source>Failed logins</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>登入失敗</target>
web/admin: always show oidc well-known URL fields when they're set (#7560) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-14 12:05:18 +00:00
</trans-unit>
<trans-unit id="sb35c08e3a541188f">
<source>Also known as Client ID.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>也稱為用戶端 ID</target>
web/admin: always show oidc well-known URL fields when they're set (#7560) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-14 12:05:18 +00:00
</trans-unit>
<trans-unit id="sd46fd9b647cfea10">
<source>Also known as Client Secret.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>也稱為用戶端密碼</target>
web/admin: always show oidc well-known URL fields when they're set (#7560) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-14 12:05:18 +00:00
</trans-unit>
<trans-unit id="s4476e9c50cfd13f4">
<source>Global status</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>全域狀態</target>
web/admin: always show oidc well-known URL fields when they're set (#7560) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-14 12:05:18 +00:00
</trans-unit>
<trans-unit id="sd21a971eea208533">
<source>Vendor</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>製造商</target>
web/admin: always show oidc well-known URL fields when they're set (#7560) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-14 12:05:18 +00:00
</trans-unit>
<trans-unit id="sadadfe9dfa06d7dd">
<source>No sync status.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>無同步的狀態。</target>
web/admin: always show oidc well-known URL fields when they're set (#7560) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-14 12:05:18 +00:00
</trans-unit>
<trans-unit id="s2b1c81130a65a55b">
<source>Sync currently running.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>正在進行同步。</target>
web/admin: always show oidc well-known URL fields when they're set (#7560) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-14 12:05:18 +00:00
</trans-unit>
<trans-unit id="sf36170f71cea38c2">
<source>Connectivity</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>連接性</target>
web/admin: fix incorrectly encoded chars in translation (#7580) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-15 15:28:56 +00:00
</trans-unit>
<trans-unit id="sd94e99af8b41ff54">
<source>0: Too guessable: risky password. (guesses &amp;lt; 10^3)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>0: 極為容易猜測，高風險密碼。（猜測次數 &amp;lt; 10^3）</target>
web/admin: fix incorrectly encoded chars in translation (#7580) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-15 15:28:56 +00:00
</trans-unit>
<trans-unit id="sc926385d1a624c3a">
<source>1: Very guessable: protection from throttled online attacks. (guesses &amp;lt; 10^6)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>1: 非常容易猜測：可抵抗受限的線上攻擊。（猜測次數 &amp;lt; 10^6）</target>
web/admin: fix incorrectly encoded chars in translation (#7580) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-15 15:28:56 +00:00
</trans-unit>
<trans-unit id="s8aae61c41319602c">
<source>2: Somewhat guessable: protection from unthrottled online attacks. (guesses &amp;lt; 10^8)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>2: 普通容易猜測：可抵抗不受限的線上攻擊。（猜測次數 &amp;lt; 10^8）</target>
web/admin: fix incorrectly encoded chars in translation (#7580) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-15 15:28:56 +00:00
</trans-unit>
<trans-unit id="sc1f4b57e722a89d6">
<source>3: Safely unguessable: moderate protection from offline slow-hash scenario. (guesses &amp;lt; 10^10)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>3: 安全難以猜測：在離線的慢速雜湊情境提供中等保護。（猜測次數 &amp;lt; 10^10）</target>
web/admin: fix incorrectly encoded chars in translation (#7580) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-15 15:28:56 +00:00
</trans-unit>
<trans-unit id="sd47f3d3c9741343d">
<source>4: Very unguessable: strong protection from offline slow-hash scenario. (guesses &amp;gt;= 10^10)</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>4: 非常難以猜測：在離線的慢速雜湊情境提供強力保護。（猜測次數 &amp;gt;= 10^10）</target>
web/admin: contextually add user to group when creating user from group page (#7586) * move related user list to group folder Signed-off-by: Jens Langhammer <jens@goauthentik.io> * contextually add user to group when created from group view page Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add banner Signed-off-by: Jens Langhammer <jens@goauthentik.io> * format Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-15 22:14:30 +00:00
</trans-unit>
<trans-unit id="s3d2a8b86a4f5a810">
<source>Successfully created user and added to group <x id="0" equiv-text="${this.group.name}"/></source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>成功建立使用者並加入到群組 <x id="0" equiv-text="${this.group.name}"/></target>
root: fix API schema for kotlin (#7601) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-16 23:07:21 +00:00
</trans-unit>
<trans-unit id="s824e0943a7104668">
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
<source>This user will be added to the group "<x id="0" equiv-text="${this.targetGroup.name}"/>".</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>這個使用者將會被加入到「<x id="0" equiv-text="${this.targetGroup.name}"/>」群組。</target>
stages/identification: add option to pretend user exists (#7610) * stages/identification: add option to pretend user exists Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update docs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * test CI permission fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-18 00:55:48 +00:00
</trans-unit>
<trans-unit id="s62e7f6ed7d9cb3ca">
<source>Pretend user exists</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>存在模擬的使用者</target>
stages/identification: add option to pretend user exists (#7610) * stages/identification: add option to pretend user exists Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix tests? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update docs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * test CI permission fix Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-18 00:55:48 +00:00
</trans-unit>
<trans-unit id="s52bdc80690a9a8dc">
<source>When enabled, the stage will always accept the given user identifier and continue.</source>
translate: Updates for file web/xliff/en.xlf in zh_TW (#7688) Translate web/xliff/en.xlf in zh_TW 100% translated source file: 'web/xliff/en.xlf' on 'zh_TW'. Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
2023-11-22 11:00:34 +00:00
<target>啟用時，該階段將始終接受給定的使用者識別碼並繼續執行。</target>
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
</trans-unit>
<trans-unit id="s5d7748b1d2363478">
<source>Are you sure you want to remove the selected users from the group <x id="0" equiv-text="${this.targetGroup?.name}"/>?</source>
web/admin: revise wizard form handling (#7331) * web: break circular dependency between AKElement & Interface. This commit changes the way the root node of the web application shell is discovered by child components, such that the base class shared by both no longer results in a circular dependency between the two models. I've run this in isolation and have seen no failures of discovery; the identity token exists as soon as the Interface is constructed and is found by every item on the page. * web: fix broken typescript references This built... and then it didn't? Anyway, the current fix is to provide type information the AkInterface for the data that consumers require. * web: extract the form processing from the form submission process Our forms have a lot of customized value handling, and the function `serializeForm` takes our input structures and creates a JSON object ready for submission across the wire for the various models provided by the API. That function was embedded in the `ak-form` object, but it has no actual dependencies on the state of that object; aside from identifying the input elements, which is done at the very start of processing, this large block of code stands alone. Separating out the "processing the form" from "identifying the form" allows us to customize our form handling and preserve form information on the client for transactional purposes such as our wizard. w * web: multi-select, but there's a styling issue. * web: provide a closed control for multi-select This commit creates a new control, using the ak-form-element-horizontal as a *CLOSED* object, for our multi-select. This control right now is limited to what we expect to be using in the wizard, but that doesn't mean it can't be smarter in the future. * web: hung up by a silly spelling error * web: update the form-handling method With the `serializeForm` method extracted, it's much easier to examine and parse every *form* with every keystroke, preserving them against the changes that happen as the customer navigates the Wizard. With that in place, it became straightforward to retrofit the "handle changes to the application, to the provider, and to the providerType" into the three pages of the wizard, and to provide *all* of the form elements in a base class such that no specialized handling needs to happen to any of the child pages. Fixed an ugly typo in the oauth2 provider, as well. * web: wizard should work with multi-select and should reflect default values (Note: This commit is predicated on both the "Extract serializeForm function from Form.ts" and "Provide a controlled multi-select input control" PRs.) The initial attempt at the wizard was woefully naive in its implementation, missing some critical details along the way. This revision starts off with one stronger assumption: trust that Jens knows what he's doing, and knew what he was building when he wrote the initial `Form` handler. The problem with the `Form` handler, and the reason I avoided it, was simply that it does too many things, especially in its ModelForm variant: it receives a model from the back-end, renders a (hand-written) form for that model, allows the user to interact with that model, and facilitates saving it to the back-end again, complete with on-page notifications of success or failure. The Wizard could not use all of that. It needs to gather the information for *two* models (an Application and a Provider, plus the ProviderType) and has a new and specialized end-point for a transaction that allows the committing or roll back of both models to happen simultaneously, predicated on success or failure respectively. With "Extract `serializeForm` completed, it was possible to repurpose the forms that already existed, stripping them down to just their input components, and eventing the entire thing in a single event loop of "events flow up, data flows down." In this case, the *entire form* is serialized on a per-event basis and pushed up the to the orchestration layer, which saves them off. Writing a parent `BasePanel` class that has accessors for `formValues` and `valid` means that the state of every page is accessible with a simple query. This simplified the `BaseProviderPanel` class to just specialize the `dispatchUpdate` method to send the wizard update with the new provider information filled out. Because the *form* is being treated as the source of truth about the state of a `Partial<Application>` or `Partial<*Provider>` object, the defaults are now being captured as expected. Likewise, this simplified the `providerCache` layer which preserves customer input in the event that the customer starts filling out the wrong provider to a simple conditional clause in the orchestrator. The Wizard has much fewer smarts because it doesn't (and probably never did) need them. Along with the above changes, the following has also been done: For SAML and SCIM, the providerMappings now works. They weren't being managed as `state` objects, so they weren't receiving updates when the update event retrieved the information from the back-end. In order to make clear what's happening, I have extracted the loops from the original definition and built them as named objects: `propertyMappings`, `pmUserValues`, `pmGroupValues` and so on, which I then pass into the new multi-select component. I fixed a really embarrassing typo in Oauth2's "advanced settings" block. I have extracted the CoreGroup search-select into a custom component. I deleted the `merge` function. That was a faulty experiment with non-deterministic outcomes, and I was never happy with it. I'm glad its gone. I've added a title header to each of the providers, so the user can be sure that they're looking at the right provider type when they start filling out the form. I've created a new token, `data-ak-control`, with which we can mark all objects that we can treat as Authentik value-producing components, the form value of which is available through a `json()` method. I've added this bit of intelligence to the `serializeForm` function, short-circuiting the complex processing and putting the "this is the shape of the value we expect from this input" *onto the input itself*. Which is where it belongs. * web: add error handling to wizard. * web: improve error handling in light components Rather than reproduce the error handling across all of the LightComponents, I've made a parent class that takes the common fields to distribute between the ak-form-element-horizontal and the input object itself. This made it much easier to properly display errors in freeform input fields in the wizard, as well as working with the routine error handling in Form.ts * Added the radio control to the list of LightComponents. * Fix bug where event was recorded twice. * Fixed merge bug (?) that somehow deleted the Authorization Select block in OAuth2. * web: prettier had opinions * web: added error handling and display * web: bump @lit-labs/context from 0.4.1 to 0.5.1 in /web Bumps [@lit-labs/context](https://github.com/lit/lit/tree/HEAD/packages/labs/context) from 0.4.1 to 0.5.1. - [Release notes](https://github.com/lit/lit/releases) - [Changelog](https://github.com/lit/lit/blob/main/packages/labs/context/CHANGELOG.md) - [Commits](https://github.com/lit/lit/commits/@lit-labs/context@0.5.1/packages/labs/context) --- updated-dependencies: - dependency-name: "@lit-labs/context" dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> * web: updated wizard to run with latest package.json configuration Apparently, there were stale dependencies in package-lock.json that were conflicting with the requests in our package.json. By running `npm update`, I was able to resolve the conflict. I have also removed the default names from the context names collection; they weren't doing any good, and they permit frictionless renaming of dependencies, which is never a good idea. * web: schlepping on the errors messages During testing, I realized I was unhappy with the error messages. They're not very helpful. By adding links to navigate back to the place where the error occurred, and providing better context for what the error could have been, I hope to help the use correct their errors. * make package the same as main Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-12-06 11:28:19 +00:00
</trans-unit>
<trans-unit id="scda8dc24b561e205">
<source>There was an error in the application.</source>
</trans-unit>
<trans-unit id="sdaca9c2c0361ed3a">
<source>Review the application.</source>
</trans-unit>
<trans-unit id="sb50000a8fada5672">
<source>There was an error in the provider.</source>
</trans-unit>
<trans-unit id="s21f95eaf151d4ce3">
<source>Review the provider.</source>
</trans-unit>
<trans-unit id="s9fd39a5cb20b4e61">
<source>There was an error</source>
</trans-unit>
<trans-unit id="s7a6b3453209e1066">
<source>There was an error creating the application, but no error message was sent. Please review the server logs.</source>
</trans-unit>
<trans-unit id="s1a711c19cda48375">
<source>Configure LDAP Provider</source>
</trans-unit>
<trans-unit id="s9368e965b5c292ab">
<source>Configure OAuth2/OpenId Provider</source>
</trans-unit>
<trans-unit id="sf5cbccdc6254c8dc">
<source>Configure Proxy Provider</source>
</trans-unit>
<trans-unit id="sf6d46bb442b77e91">
<source>AdditionalScopes</source>
</trans-unit>
<trans-unit id="s2c8c6f89089b31d4">
<source>Configure Radius Provider</source>
</trans-unit>
<trans-unit id="sfe906cde5dddc041">
<source>Configure SAML Provider</source>
</trans-unit>
<trans-unit id="sb3defbacd01ad972">
<source>Property mappings used for user mapping.</source>
</trans-unit>
<trans-unit id="s7ccce0ec8d228db6">
<source>Configure SCIM Provider</source>
</trans-unit>
<trans-unit id="sd7728d2b6e1d25e9">
<source>Property mappings used for group creation.</source>
events: add graph for event volume (#7639) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-12-06 17:06:07 +00:00
</trans-unit>
<trans-unit id="s7513372fe60f6387">
<source>Event volume</source>
sources/ldap: add support for cert based auth (#5850) * ldap: support cert based auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> * ldap: default sni switch to off * ldap: `get_info=NONE` on insufficient access error * fix: Make file locale script * ldap: add google ldap attribute mappings * ldap: move google secure ldap blueprint to examples Revert "ldap: add google ldap attribute mappings" This reverts commit 8a861bb92c1bd763b6e7ec0513f73b3039a1adb4. * ldap: remove `validate` for client cert auth not strictly necessary * ldap: write temp cert files more securely * ldap: use first array value for sni when provided csv input * don't specify tempdir we set $TMPDIR in the dockerfile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * limit API to only allow certificate key pairs with private key Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use maxsplit Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens L. <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-12 13:41:44 +00:00
</trans-unit>
web: Replace lingui.js with lit-localize (#5761) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
2023-06-02 15:08:36 +00:00
</body>
</file>
web: fix locale (#7689) Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2023-11-22 13:50:13 +00:00
</xliff>